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PREFACE 


This  User  Manual  provides  detailed  Instructions  for  the  preparation 
and  definition  of  databases  to  be  processed  by  Version  IIA  Release  2 Data 
Translator.  The  Version  IIA  Release  2 Translator  Is  the  third  prototype 
Implementation  of  a generalized  data  conversion  and  restructuring  capability 
developed  by  the  University  of  Michigan  for  CCTC/WAD.  It  Is  the  first 
"operational"  translator  and  therefore  should  be  considered  experimental 
In  feature.  Our  purpose  In  releasing  the  translator  and  associated  Users 
Manual  Is  to  allow  the  User  Community  a chance  to  use  and  comment  on  the 
desirability  of  this  capability  and  documentation.  Such  feedback  would 
provide  the  basis  for  Improved  documentation  and  software  capability. 

It  Is  asstaned  that  the  reader  has  a reasonably  high  level  of  Honeywell 
expertise.  Specifically,  the  user  should  be  familiar  with: 

Sequential,  ISP,  and  IDS  files 

Control  card  sequences 

IDS  database  design 

Timesharing 


Please  address  all  comments  to  both 


Mr.  James  P.  Fry 

Data  Translation  Project 

Graduate  School  of  Business  Administration 

University  of  Michigan 

Ann  Arbor,  Michigan  48109 

(313)  763-1100 
(703)  471-4227 
(703)  471-1024 
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Mr.  Paul  Rubin,  C420 
Defense  Communications  Agency 
11440  Isaac  Newton  Square,  N. 
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1.0  INTRODUCTION  TO  DATA  TRANSLATION 

The  Data  Translation  Project  at  the  University  of  Michigan  has 
developed  a Data  Translator  which  is  capable  of  reorganizing  WWDMS 
databases  (Sequential,  ISP,  and  IDS)  by  altering  the  logical  structure 
and  by  modifying  the  physical  structure.  The  work  was  completed  on  a 
Honeywell  6060  computer  under  a contract  from  the  Command  and  Control 
Technical  Center  WVIMCCS  ADP  Directorate  (Code  400)  of  the  Defense 
Communications  Agency.  The  Data  Translator  is  a complex  and  sophisti- 
cated software  package,  yet  is  understandable  and  easy  to  use.  This  manual 
describes  the  capabilities  of  the  Data  Translator,  how  to  use  the  software, 
and  an  example  of  its  use. 

1 . 1 Background  to  Translation 

This  Data  Translator  is  the  product  of  many  years  of  research  and 
development.  Previous  Translators  lacked  many  of  the  features  of  the  current 
release.  Refer  to  Table  1-1  for  a comparison  of  Data  Translator  features. 

The  Version  I was  developed  to  show  the  feasibility  of  the  generalized  Data 
Translator.  Version  II  was  to  be  an  extension  of  Version  I since  it  was 
capable  of  handling  tree-type  data  structures.  The  Version  IIA  Release  1 was 
designed  in  response  to  the  demand  for  a network  Data  Translator.  The 
Release  2 overcomes  Release  1's  performance  problems  and  presents  some  new 
features.  All  of  the  capabilities  of  the  Release  2 Data  Translator  are 
detailed  in  Section  1.2. 

Originally,  when  a user  needed  to  represent  his  data  in  a new  way,  he 
would  write,  or  have  written,  a program  to  change  the  data  (Figure  1-1). 

If  a different  data  representation  were  required,  another  program  was  needed. 
The  cost  of  data  translation  was,  therefore,  very  high  since  a large  amount 
of  programming  effort  was  used  in  a one  time  application. 

The  current  state-of-the-art  approach  to  data  translation  is  to  use  a 
generalized  data  translator  (Figure  1-2).  This  approach  is  exemplified  by 
the  Version  IIA  Release  2 Data  Translator.  The  generalized  approach  uses 
programs  which  have  been  written  and  descriptions  of  the  old  and  new  data- 
bases (herein  referred  to  as  source  and  target  databases)  and  of  the  trans- 
formation between  source  and  target  databases.  The  architecture  of  the 
Data  Translator  will  be  described  in  Section  1.3. 

1 . 2 Capabilities  and  Limitations  of  the  Version  IIA  Release  2 Data  Translator 

1.  Up  to  five  source  databases  can  be  combined  and  restructured.  The 
source  databases  may  comprise  any  combination  of  WWDMS  sequential, 

ISP  or  IDS  databases. 

2.  Up  to  five  target  databases  can  be  written.  The  target  databases 
must  be  legal  IDS  databases. 

3.  The  physical  structure  of  the  target  database  may  be  different  from 
that  of  the  source  database.  Therefore,  page  range,  page  size, 

PLACE  NEAR,  etc.,  can  be  changed  to  improve  database  performance. 

4.  User- implemented  relations,  such  as  phantom  chains,  pointer  arrays, 
or  match -keys,  within  and  between  source  databases  can  be  restruc- 
tured into  legal  IDS  chains  in  the  target  database. 


Date  I Source  Target  Language  Typical  Internal 

Completed  I DBMS  DBMS  Restructuring  Analyzers  t CPU  Time  * Data  Model 


New  Database 


1 


Figure  1-1 

Conversion  Program  Approach  to  Data  Translation 


Data 

Translator 


New  Database 


Old  Database 


Figure  1-2 

Data  Translator  Approach  to  Data  Translation 
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5.  Conta 1 ned-1 n-repeat 1 ng  grbups  at  the  03-49  level  In  the  source 
database  can  be  expanded  Into  their  own  01  level  record  types  to 
become  the  detail  of  the  01  record  In  which  they  were  contained. 

6.  Data  Items  can  be  added, : deleted  or  have  their  physical  representa- 
tion altered  between  the  source  and  target  databases. 

7.  Relations  between  records  can  be  added,  deleted  or  modified 
between  the  source  and  target  databases  depending  on  user-specified 
criteria. 

8.  Records  can  be  added,  deleted,  or  have  their  Item  contents  changed 
between  the  source  and  target  databases,  depending  on  user- 
specified  criteria. 

9.  New  record  types  can  be  created  In  the  target  database  from 
aggregations  of  source  records.  Duplicate  data  can  be  eliminated 
or  created. 

10.  To  facilitate  the  translation  of  large  databases,  the  translation 
process  can  be  stopped  and  restarted  at  a later  time. 


1.3  Overview  of  Translation 

There  are  many  reasons  why  a user  would  desire  a new  database  structure. 
Common  reasons  Include  the  need  to  satisfy  new  processing  requirements,  and 
performance  Improvement.  For  example,  suppose  a company  had  the  following 
ISP  data  structure  relating  divisions  In  the  company.  Its  products,  suppliers 
and  parts: 


Figure  1-3 
Source  Database 


This  Implementation  of  the  database  ms  Initially  successful,  but  since 
the  company  has  grown  and  Increased  Its  product  line,  the  old  database  Is 
no  longer  sufficient.  This  Inadequacy  stems  from  the  following  reasons; 

1.  Updating  parts  records  takes  a long  time  since  parts  data  Is 
stored  In  both  S-PARTS  and  C-PARTS  records. 

2.  Direct  access  of  either  parts  record  Is  slow  due  to  extra  time 
spent  searching  overflow  chains. 

3.  Parts  reports  are  hard  to  produce  due  to  the  duplicate  part 
data. 

The  database  administrator  of  the  company  has  recognized  these  problems 
and  decided  that  an  IDS  database  with  the  following  structure  will  perform 
better: 


Division 


.Has-Products 


Has-Suppl  ier: 


Products 


Contalns-Parts 


Supplles- 

Parts 


Parts 


CALC- Parts 


Figure  1-4 


This  example  shows  a simple,  but  Important  application  of  the  Data  Transla 
tor.  Much  more  complex  transformations  can  be  performed. 


1.3.1  Preliminary  Procedures 

To  operate  the  Data  Translator,  a user  must  understand  the  connections 
and  data  flow  between  modules  and  the  module-user  Interfaces.  This  section 
Is  Intended  to  give  a high-level  view  of  the  Data  Translator  modules.  More 
specific  Information  about  each  module  will  be  given  In  succeeding  sections. 

Before  execution  begins,  the  database  administrator  should  perform  an 
analysis  of  the  requirements  for  the  target  database.  This  Involves  drawing 
an  IDS  database  diagram,  writing  an  IDS  MD  section  for  the  target,  and 
determining  how  the  records  and  chains  in  the  target  will  be  created  from 
the  source  database. 

Because  the  Data  Translator  allows  the  transformation  of  the  user- 
implemented  relations  Into  IDS  chains  the  database  administrator  should 


examine  the  source  database  for  these  non-IDS  constructs.  If  their  Informa 
tlon  Is  to  be  preserved  In  the  target,  then  explicit  specification  of  the 
relation  will  be  necessary  In  order  for  the  Data  Translator  to  be  aware 
of  their  existence. 


1.3.2  The  Data  Translation  Process 

To  perform  completely  the  data  translation  procedure,  the  user  must 
complete  six  separate  steps,  The  first  two  steps  Involve  writing  descrip- 
tions of  the  source  and  target  databases  using  their  MD  sections  and  level 
61  extensions.  Those  descriptions  should  be  run  through  the  IDS  Analyzer 
to  produce  source  and  target  SODL  (Stored  Data  Definition  Language) 
tables.  The  third  step  Is  encoding  the  source-to-target  transformation  In 
the  TDL  (Translation  Definition  Language)  and  running  the  TDL  Analyzer  to 
produce  TDL  tables.  The  fourth  step.  Reader  execution,  creates  the 
Restructurer  Internal  Form  (RIF)  of  the  source  database(s).  The  Restruc- 
turer  produces  the  target  RIF  database  In  the  fifth  step.  The  target  IDS 
database(s)  Is  produced  by  running  the  Writer.  The  entire  Data  Translation 
process  Is  shown  In  Figure  1-5  and  an  example  Is  Included  In  Section  11. 


1.3.3  Database  Description 

The  Data  Translator  Is  a description-driven  process.  The  translation 
modules  must  know  the  format  of  the  source  and  target  databases  and  the 
rules  for  creating  records  and  chains  In  the  target  database  from  the 
records  and  chains  In  the  source  database. 

The  descriptions  of  the  source  and  target  databases  are  the  source 
and  target  MD  sections  and  additional  Information  needed  to  restructure 
the  'tabase.  If  the  source  database  Is  IDS,  no  new  source  MD  section  Is 
rw  sary.  If  the  source  database  Is  WWDMS  Sequential  or  ISP,  however, 
a S MD  which  describes  the  source  database  will  have  to  be  written. 

A MD  section  for  the  target  database  will  also  have  to  be  written. 

Ai  the  MD  sections  have  been  collected  or  written,  and  additional  Infor- 

ma on  encoded  as  special  level  61  statements,  the  extended  MDs  are  ready 
to  be  used.  The  IDS  Analyzer  uses  the  extended  MD  sections  to  produce  source 
and  target  SDDL  tables.  These  first  two  steps  are  shown  In  Figure  1-6. 

The  SDDL  tables  are  databases  which  hold  Information  describing  the 
source  or  target  database.  SDDL  tables  are  analogous  to  the  IDS  Definition 
Structure  which  describes  IDS  databases.  If  multiple  source  or  target  data- 
bases have  been  described,  there  will  be  only  one  source  or  target  SDDL 
tables  file.  Writing  61  levels  Is  described  In  Section  3;  running  the  IDS 
Analyzer  Is  described  In  Section  5. 

The  final  description  to  be  written  details  the  transformation  between 
the  source  and  target  databases.  That  description  must  be  written  in  the 
Translation  Definition  Language  (TDL).  The  TDL  describes  how  to  create 
target  records  using  the  source  records  and  chains.  It  Is  imperative  that 
the  TDL  description  be  correct  and  validated.  If  the  user  does  not  write 
the  TDL  description  properly,  the  output  of  the  Translator  will  be  Invalid 
and  the  Restructuring  will  have  to  be  repeated. 

The  third  step  of  the  Translation  process  Is  running  the  TDL  descrip- 
tion through  the  TDL  Analyzer  to  produce  TDL  tables.  The  TDL  tables  cannot 
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be  created  until  both  source  and  target  SODL  tables  have  been  created.  The 
TDL  tables  are  an  Internal  representation  of  the  TDL  description  which  the 
Restructurer  can  conveniently  use.  TDL  analysis  Is  shown  In  Figure  1-7. 
Writing  the  TDL  Is  shown  In  Section  4 and  running  the  TDL  Analyzer  Is 
described  In  Section  6. 


Figure  1-7 

Step  Three  - Creating  TDL  Tables 


1.3.4  Data  Translation  Modules 

The  final  three  steps  In  the  Data  Translation  procedure  are  the 
executions  of  the  Reader,  Restructurer  and  Writer  modules.  In  that  order. 
The  Reader  converts  the  source  database(s)  Into  a logically  equivalent 
ADBMS  database  called  the  Source  RIF.  (See  Appendix  F for  a description 
of  ADBMS.)  The  Restructurer  converts  the  Source  RIF  Into  an  ADBMS  data- 
base called  the  Target  RIF  which  Is  logically  equivalent  to  the  target 
IDS  databases.  Finally,  the  Writer  produces  the  desired  IDS  database(s) 
from  the  Target  RIF. 


1.3. 4.1  The  Reader 
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There  are  three  Reader  modules,  one  each  for  WWDMS  Sequential,  ISP 
and  IDS  file  systems.  They  all  sequentially  access  the  source  database(s) 
and  produce  a logically  equivalent  Source  Restructurer  Internal  Form  data- 
base (SRIF).  The  IDS  Reader  requires  a COBOL-IOS  program  containing  the 
MD  section  for  that  Source  IDS  database  to  be  compiled  before  the  Reader 
can  be  run.  Figure  1-8  shows  the  Reader  process  and  the  Reader  Is 
described  In  Section  7. 

1.3. 4. 2 The  Restructurer 


The  heart  of  the  Data  Translator  Is  the  Restructurer  module.  It 
uses  Information  stored  In  the  TDL  tables  to  create  a target  RIF  from  the 
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Figure  1-8 

Step  Four:  Creating  the  Source  RIF 


data  In  the  source  RIF.  The  Restructured  data  model  used  In  the  RIF  Is 
described  In  Section  2.2;  running  the  Restructurer  Is  described  In  Section 
8.  Figure  1-9  shows  the  Restructurer  process. 


Target 


Restructurer 


Source 


Tables 


Figure  1-9 

Step  Five:  Creating  the  Target  RIF 


1.3. 4. 3 The  Writer 


The  last  step  of  the  Translation  process  Is  running  the  Writer.  The 
Writer  populates  the  target  IDS  database(s)  using  the  target  RIF  and  the 
target  SDDL  tables.  To  optimize  record  storage  as  the  user  would  desire, 
the  IDS  routines  are  called  actually  to  place  the  records  Into  the  target 
flle(s)  and  correctly  link  them.  This  requires  that  the  target  IDS  HD 
sectlon(s)  be  compiled  Into  a COBOL-IDS  program  before  running  the  Writer 
The  Writer  Is  shown  In  Figure  1-10  and  running  the  Writer  is  detailed  In 
Section  9. 


1.4  Definition  of  Terms 

Access  Path  a hierarchical  substructure  of  the  source  RIF  which 
defines  a representation  of  a target  record  type 
In  the  source  RIF. 

Accessor  a module  In  the  Reader  which  retrieves  records  from  the 

source  database. 

ADBMS  a DBTG-Ilke  database  management  system  used  by  the 

Data  Translator. 

Bachman  Diagram  a figure  which  represents  the  schema  of  a database. 

Record  types  are  represented  by  boxes;  set  types  are 
represented  by  lines  connecting  record  type  boxes. 
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Chain  (IDS)  IDS's  physical  means  of  linking  records  together  into 
relations.  All  chains  are  mapped  as  linked  lists. 

The  A DBMS  equivalent  is  a set. 

Contained- in- Repeating  Group  (CIRG)  a named  collection  of  items  in 

a record.  In  COBOL-IDS,  a CIRG  is  defined  as  any  field 
with  an  OCCURS  clause. 

Constructor  the  Restructurer  module  that  physically  creates  an 

ADBMS  target  group  instance  in  the  target  RIF,  moving 
the  proper  data  items  from  the  source  instances  into 
the  target  instance. 

Currency  (ADBMS)  various  ADBMS  subroutines  are  used  to  set  currency 
indicators.  A record  instance  may  become  (and  later  be 
referred  to  as)  (1)  the  current  instance  of  its  record 
type,  (2)  the  current  owner  instance  of  zero  or  more 
set  types,  and  (3)  the  current  member  instance  of  zero 
or  more  set  types.  A record  instance  retains  all  its 
currency  until  the  currency  indicators  referring  to  it 
are  specific  ally  changed  by  another  ADBMS  subroutine 
(i.e.,  changed  to  refer  to  another  record  instance  or 
to  be  null).  The  ADBMS  current  database  indicator 
is  used  to  distinguish  the  database  currently  in  use 
from  the  other  open  databases  and  may  be  set  and  reset 
by  the  ADBMS  user. 

Currency  (IDS)  for  purposes  of  retrieval,  every  chain  type  has  a 

current  record  Instance  at  any  given  time.  There  is  also 
a current  record  instance  for  each  record  type  at  any 
given  time.  A current  record  instance  is  generally 
the  last  record  instance  stored,  retrieved,  or  modified. 

Database  Dump  output  similar  to  a core  dump,  consisting  of  the  contents 
of  a database  usually  in  both  octal  and  character  format. 
Each  database  page  is  dumped  in  its  entirety  (i.e., 
page  headers,  etc.,  are  included)  for  debugging  purposes. 

Database  Initializer  (ADBMS)  before  a file  can  be  used  to  hold  an 
ADBMS  database,  It  must  be  processed  by  the  Database 
Initializer.  The  file  is  overwritten  with  zeroes, 
partitioned  into  pages,  and  each  page  is  initialized 
with  a page  header  record.  The  ADBMS  DBT  is  written 
onto  the  file  starting  at  page  one.  A record  of  the 
type  SYSTEM  is  placed  on  the  page  following  the  DBT. 

Database  Initializer  (IDS)  all  IDS  databases,  upon  their  creation, 
must  be  initialized  with  page  header  records  before 
any  data  can  be  stored  In  them.  This  is  done  via 
utility  routine  QUTI. 

Database  Name  the  string  of  characters  after  the  database  declara- 
tion In  the  IDS  Analyzer's  run-time  parameter  file. 

This  name  Is  used  by  the  Reader  and  Writer  modules  to 
establish  currency  in  the  SDDl.  tables. 


1-15 


Database  Tables  (DBT)  the  output  of  the  DDL  Analyzer.  These  tables 
contain  a description  of  the  database  schema  In  a form 
usable  by  AOBMS  and  are  stored  In  the  first  pages  of 
the  database. 

Database  Tables  File  (DBTF)  a sequential  file  which  contains  the 
Database  Tables  for  a database. 

DDL  - Data  Definition  Language  a language  used  to  describe  the  schema 
of  a database  In  terms  of  the  three  basic  ADBMS  constructs 
the  Item,  the  record,  and  the  set.  DDL  text  serves  as 
Input  to  the  DDL  Analyzer. 

DOL  Analyzer  a language  analyzer  that  accepts  as  Inputs  ADBMS  DDL  and 
produces  as  output  Database  Tables  (DBT). 

DDL  Writer  a module  that  scans  SDDL  tables  and  produces  as  output 
ADBMS  DDL  text  suitable  for  Input  to  the  DDL  Analyzer. 

DDL  Writer  Work  Database  an  ADBMS  database  used  by  the  DDL  Writer. 

Detail  every  relation  In  IDS  has  one  parent  record  type  and  up 

to  99  dependent  record  types.  The  dependent  of  a chain 
Is  called  a detail.  The  ADBMS  equivalent  Is  a member. 

DRT  (Deferred  Reference  Table)  an  ADBMS  database  used  by  the 

populator  to  maintain  Information  about  subsets  In  the 
source  RIF. 

Extended  MD  Section  to  describe  databases  to  the  Data  Translator, 
the  source  and  target  MD  sections  are  augmented  with 
additional  Information.  The  additional  data  Is  repre- 
sented with  level  61  entries. 

Field  (ADBMS)  see  Item  (ADBMS). 

Field  (IDS)  IDS  records  are  comprised  of  elementary  items  (fields) 
that  represent  a unit  of  data.  IDS  Is  aware  of  fields 
only  at  the  02  level. 

Group  see  record  (ADBMS). 

Hash  Database  (ADBMS)  an  ADBMS  database  which  contains  one  or  more 
hash  record  types. 

Hash  Input  (ADBMS)  Input  required  by  the  Database  Initializer  when 
Initializing  hash  databases. 

Hash  Record  (ADBMS)  an  ADBMS  record  type  whose  Instances  are  stored 
and  retrieved  by  hashing,  l.e.,  calculating  the  record's 
address  by  randomizing  on  the  primary  key. 

IDS  (Integrated  Data  Store)  a network  database  management  system 

on  the  Honeywell  H-6000  used  as  a source  and  the  target 
of  translation. 

IDS  Analyzer  A Data  Translator  module  that  accepts  an  extended  MD 
section,  which  describes  a user's  database  In  textual 
form  and  produces  SDDL  tables  which  are  used  by  other 
translator  modules. 
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IDS  Query  Dictionary  an  IDS  database  produced  from  the  extended  MD 
section  by  the  IDS  Translator  In  query  mode.  It  Is 
read  In  as  Input  to  the  IDS  Analyzer. 

IDS  Structure  Table  produced  as  the  common  area  .IDS.,  by  every  IDS 
compilation.  It  Is  an  internal  encoded  table  that 
describes  an  IDS  database.  It  Is  formally  known  as  the 
IDS  Definition  Structure. 

IDS  Translator  The  IDS  compiler  Invoked  via  the  $IDS  card.  When 

configured  In  query  mode,  the  IDS  Translator  produces 
the  IDS  Query  dictionary. 

Incremental  Reading  the  process  of  reading  a source  IDS  database  in 
multiple  runs  of  the  IDS  Reader.  The  IDS  Reader  can  be 
used  to  process  the  source  database  In  a user-specified 
number  of  runs. 

Instance  an  occurrence  of  one  object  within  a type  or  class,  as 

distinguished  from  type.  Example:  an  Instance  of 
record  type  PERSON  Is  "JOHN  SMITH". 

ISP  an  1 ndexed-sequentl al  file  organization.  Databases  In 

ISP  form  (If  conforming  to  WWDMS  T-Z  rules)  can  be 
converted  to  IDS  databases  by  the  Data  Translator. 

Item  (ADBMS)  the  elementary  unit  of  data  in  an  ADBMS  record. 

Synonymous  with  field. 

Item  (IDS)  see  Field  (IDS). 

Item  Conversion  since  only  certain  data  types  are  supported  by  the 
Restructurer  the  Reader  and  Writer  must  perform  item 
conversion  for  IDS  Items  (fields)  that  are  in  data 
formats  supported  by  IDS  but  not  by  the  Restructurer. 

Library  a file  used  to  hold  the  object  modules  of  several 

logically  or  functionally  related  subroutines. 

Logically  Deleted  Record  (ADBMS)  a record  In  an  IDS  database  which 
has  been  flagged  as  deleted  but  has  not  yet  been 
physically  deleted  from  the  database. 

Master  every  relation  type  In  IDS  has  one  parent  record  type 

and  up  to  99  detail  record  types.  The  parent  of  a 
chain  Is  called  a master.  The  ADBMS  equivalent  is  owner. 

Match- Key  Relation  a non- IDS  relation  between  record  types  In  the 
source  database(s).  Implemented  by  having  Identical 
Item  values  In  different  record  Instances. 

Match-Key  Set  (ADBMS)  an  ADBMS  set  Implemented  by  storing  the  primary 
key  of  the  owner  record  Instance  In  the  set-significant 
Items  of  one  or  more  member  record  Instances. 

Member  a dependent  record  type  In  an  ADBMS  set  Is  called  a 

member.  The  IDS  equivalent  Is  detail. 
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Page  (IDS) 


Multiple  Database  (ADBMS)  refers  to  the  fact  that  the  Data  Trans- 
lator must  have  several  databases  open  at  the  same 
time  (SDDL  tables,  TDL  tables,  source  and  target  RIFs, 
etc.).  The  multiple  database  capability  is  part  of 
ADBMS. 

Multiple  Database  (User)  the  Data  Translator  has  the  capability  to 
accept  as  many  as  five  source  database  schemas  (IDS, 

ISP,  or  sequential  or  any  combination  thereof)  and 
produce  as  many  as  five  target  IDS  databases.  Each 
target  database  can  be  derived  from  some  or  all  of  the 
source  databases. 

Owner  a parent  record  type  in  an  ADBMS  set  is  called  an  owner. 

The  IDS  equivalent  is  master. 

Page  (ADBMS)  an  ADBMS  database  is  made  up  of  one  or  more  database 

pages.  The  page  is  the  smallest  unit  that  can  be  moved 
from  mass  storage  to  core  and  back.  The  ADBMS  page 
length  is  1024  words. 

Page  (IDS)  an  IDS  database  is  broken  into  physical  access  units 
called  pages.  Each  page  in  a subfile  is  of  identical 
size  and  must  be  a multiple  of  64  words. 

Partial  Writing  the  process  of  outputting  a target  database  over 
several  execution  runs.  Permits  the  user  to  write  a 
target  file  when  computer  time  resources  are  constrained. 

Phantom  Pointer  Relation  a set  or  relation  in  an  IDS  database  which 
is  maintained  by  the  user.  Set  membership  is  based  or. 

IDS  reference  codes  stored  in  user  data  items. 

Physically  Deleted  Record  (ADBMS)  see  Logically  Deleted  Record  (ADBMS), 

Physically  Deleted  Record  (IDS)  a record  which  was  logically  deleted 
from  an  IDS  database, has  been  removed  from  all  of  its 
sets  and  its  space  on  the  page  reclaimed. 

PI  ex  Group  a group  or  record  in  a network  database  that  is  a 

member  of  more  than  one  set  type  (ADBMS)  or  chain  type  (IDS). 

Pointer  Array  a CIRG  in  an  IDS  database  in  which  the  user  has  stored 
IDS  reference  codes,  (see  also  Phantom  Pointer). 

Populator  a module  in  the  Reader  which  controls  the  set  linking 

process  in  the  source  RIF. 

Primary  Key  (ADBMS)  a collection  of  data  items  in  an  ADBMS  hash 

record  type  whose  combined  values  uniquely  determine  an 
instance  of  the  hash  record  type  and  are  used  in  the 
storage  and  retrieval  process. 


Qualification 

Qualifier 

Query 


in  the  restructuring  process,  the  testing  of  source  item 
values  to  determine  if  and/or  how  a target  group  instance 
is  to  be  built. 

the  Restructurer  module  that  performs  qualification. 

a request  to  a database  for  information  that  satisfies 
one  or  more  specified  criteria.  The  request  is  made  via 
the  Database  Management  System. 
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Reader  the  Translator  module  which  transforms  the  user's 

database(s)  Into  a logically  equivalent  ADBMS  database 
(source  RIF).  There  are  three  Reader  modules:  one 
each  for  IDS,  ISP,  and  Sequential  files. 

Real  Parent  the  actual  owner  Instance  of  a set  Instance  In  the  source 
RIF.  (see  also  Surrogate  Parent). 

Record  (ADBMS)  a named  collection  of  zero  or  more  Items.  Synonymous 
with  group. 

Record  (IDS)  a named  collection  of  zero  or  more  fields. 

Reference  Code  each  record  Instance  within  an  IDS  database  has  a 
logical  address  which  Is  unique.  This  address  Is 
known  as  a reference  node  and  Is  divided  Into  two 
parts  - a page  number  and  a line  number  within  that 
page. 

Relation  synonymous  with  set  (ADBMS)  and  chain  (IDS). 

Restructurer  the  Translator  module  that  produces  the  target  RIF 
from  the  source  RIF  and  the  TDL  tables. 

Restructuring  the  process  of  altering  the  logical  structure  or 
schema  of  a database. 

Restructurlng-by-Parts  the  process  of  restructuring  a database  using 
several  Restructurer  runs  as  opposed  to  a single  run. 

Each  run  processes  only  a few  access  paths  at  a time. 

The  target  records  produced  by  each  run  are  stored  In 
the  same  target  RIF. 

RIF  (Restructurer  Internal  Form)  the  standardized  database  format 
provided  by  ADBMS  along  with  certain  restrictions 
required  by  the  Version  IIA  Release  2 restructuring 
algorithm. 

Run-time  Parameter  a data  value,  used  as  Input  to  a program,  which 
Is  specified  In  the  JCL. 

Run-time  Parameter  File  a data  area  from  which  run-time  parameters 
are  read. 

Schema  a description  of  the  logical  structure  of  a database. 

SDDL  Tables  the  output  of  the  IDS  Analyzer.  The  SDDL  tables  are  an 

ADBMS  database  In  which  all  the  Information  contained 
In  the  extended  MD  section  Is  stored. 

Sequential  Database  any  user  database  not  under  the  control  of  ISP  or 
IDS,  e.g.,  a system  standard  format  file,  manageable 
by  GFREC.  The  Data  Translator  will  accept  sequential 
databases  as  Input  to  the  Reader  provided  that  they 
conform  to  WWDMS  T-2  restrictions. 
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Set  an  ADBMS  construct  used  to  define  a relationship  between 

two  record  types  known  as  the  owner  and  the  member 
record  types  for  the  set  type.  An  Instance  of  an 
ADBMS  ordered  set  Is  always  Implemented  as  a linked  list 
consisting  of  one  Instance  of  the  owner  record  type  for 
that  set  type  and  one  or  more  Instances  of  the  member 
record  type  for  that  set  type.  An  Instance  of  an  ADBMS 
match-key  set  always  consists  of  one  Instance  of  the 
owner  record  type  and  one  or  more  Instances  of  the  member 
record  type. each  having  the  primary  key  of  the  owner  record 
Instance  In  their  set-significant  Items.  The  IDS  equiva- 
lent of  the  ADBMS  ordered  set  Is  the  chain. 

Set-Significant  Items  (ADBMS)  a collection  of  data  Items  In  the  member 
record  type  of  a match-key  set.  The  Items  establish  a 
member  record  Instance  In  a match-key  set  Instance  when 
they  contain  the  primary  key  of  an  owner  record  Instance. 


Sibling 


Source  Accessor 


Source  Group 


an  IDS  record  type  which  Is  a detail  of  a chain  type 
which  also  has  other  detail  record  types. 

a Restructurer  module  that  accesses  record  Instances  In 
the  source  RIF,  driven  by  the  stack  that  was  passed  to 
It  by  the  Stack  Builder. 

an  ADBMS  record  or  group  (either  type  or  Instance)  In 
the  source  RIF.  (Abbreviated  SGROUP,  SG). 


SRIF  (Source  RIF)  an  ADBMS  RIF  database  which  Is  produced  by  the  Reader 
from  the  user's  source  database(s). 


Stack  Builder 


Subfile 


Subset 


a Restructurer  module  that  reads  access  paths  In  tree 
format  from  the  TDL  tables  and  produces  a stack  which 
drives  the  Source  Accessor. 

a file  which  contains  part  of  an  IDS  database.  IDS 
databases  can  be  divided  Into  many  GCOS  physical  files 
for  a variety  of  reasons. 

a set  Instance  In  the  source  RIF  which  contains  fewer 
record  Instances  than  the  same  set  Instance  In  the  IDS 
database.  Note  that  a set  Instance  In  the  IDS  database 
may  be  composed  of  many  subsets. 


Surrogate  Parent  a dummy  record  created  In  the  source  RIF  by  the  Populator. 


System  Access  Set 


In  an  RIF  database,  each  record  type  Is  a member  of 
a system-owned  set  type  called  Its  System  Access  Set. 
All  Instances  of  each  record  type  are  made  members  of 
their  System  Access  Set  for  ease  of  retrieval. 


System  Entry  Point  those  records  In  a database  schema  from  which  a 

database  traversal  may  start.  Examples  are  CALC  records, 
or  the  top  record  In  a tree  structure.  Furthermore,  a 
relation  Is  defined  by  the  IDS  Analyzer  In  which  the  system 
entry  point  record  Is  the  member  and  the  SYSTEM  record  Is 
the  owner. 


System  Generation  Tape  a tape  which  contains  all  of  the  files  and 
JCL  necessary  to  run  the  Data  Translator. 

SYSTEM  Record  every  ADBMS  database  has  exactly  one  Instance  of  record 
type  SYSTEM  placed  In  the  database  by  the  Database 
Initializer.  The  SYSTEM  record  Instance  allows  the 
user  to  "enter"  the  database  using  ADBMS  sets  since 
It  Is  always  the  current  SYSTEM  record. 

Target  6roup  (Target  Record)  an  ADBMS  record  (either  type  or  Instance) 

In  the  target- RIF  (Abbreviated  TGROUP,  TG). 

Target  Relation  (Target  SET)  an  ADBMS  set  (either  type  or  Instance)  In 
the  target  RIF. 

TDL  Translation  Definition  Language,  a language  used  to  describe 

the  mapping  of  the  logical  structure  of  the  source  RIF  to 
the  logical  structure  of  the  target  RIF. 


TDL  Analyzer 


TDL  Tables 


a language  analyzer  that  accepts  as  Input  TDL  text  and 
produces  as  output  TDL  tables. 

the  output  of  the  TDL  Analyzer.  The  TDL  tables  are  an 
ADBMS  database  In  which  all  the  Information  contained 
In  the  TDL  text  Is  stored. 


Translation  Library  a GCOS  library  file  containing  all  of  the  ADBMS, 

GMAP  and  utility  routines  needed  to  run  the  Data  Translator. 

TRIF  (Target  RIF)  the  ADBMS  RIF  database  that  Is  produced  by  the  Restruc- 
turer  from  the  source  RIF  and  the  specification  In  the 
TDL  tables. 

Type  a class  of  objects,  as  opposed  to  an  Instance  or 

occurrence  of  an  object  of  a type  (e.g.,  a record  type 
PERSON  is  composed  of  Item  types  NAME,  AGE,  and  SS  NUM). 

User  Conversion  Routine  a user-written  routine  that  performs  conversions 
on  source  RIF  item  values  before  they  are  assigned  to 
Items  In  the  target  RIF  records.  The  existence  of  a 
converison  routine  Is  declared  In  the  TDL  description. 

The  conversion  routine  Is  called  by  the  Constructor  when 
the  target  record  Instances  are  being  built  by  the 
Restructurer. 

User  Input  Directives  user-supplied  textual  statements  that  control 

certain  aspects  of  a Restructurer  run,  e.g.,  whether  or 
not  debug  output  Is  to  be  produced. 

User  Input  Processor  a Restructurer  module  that  processes  the  User 
Input  Directives. 

User  Qualification  Routine  a user-written  routine  which  performs  a 
particular  type  of  qualification.  The  existence  of  a 
qualification  routine  Is  noted  In  the  TDL  tables.  It 
Is  called  by  the  Qualifier  when  the  target  group  Instances 
are  being  built  by  the  Restructurer. 


! 
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Writer 


the  final  translation  module.  Its  job  is  to  transfer 
data  records  from  the  target  RIF  into  the  target  IDS 
database  preserving  all  information  content. 


1.5  Resource  Requirements 

The  Data  Translator  can  be  used  only  on  Honeywell  6000  and  600  series 
computers.  The  following  conditions  must  be  satisfied  to  run  the  Data 
Translator. 

1.  IDS  must  be  in  use.  ISP  must  be  available  to  translate  ISP  data- 
bases. 

2.  One  processor  and  at  least  256K  of  core  must  be  available. 

3.  Secondary  storage  (disk)  at  least  three  times  larger  than  the  size 
of  the  source  or  target  databases  should  be  available. 

4.  One  9-track  tape  drive  should  be  available. 

5.  IDS  Data  Query  must  be  available. 


1.5.1  Hardware  Configuration 

It  is  difficult  to  determine  an  optimal  system  configuration  for  the 
Data  Translator  since  each  application  and  installation  is  unique.  But, 
there  are  some  rules  to  follow  which  will  help  to  improve  efficiency. 

1.  Each  module  has  an  estimated  records/hour  (CPU)  rate.  It  is  based 
on  fifty  to  seventy-five  characters  per  average  record.  Do  not 
attempt  to  translate  more  data  than  is  physically  possible  given 
existing  computer  time  constraints.  Make  full  use  of  the  partial 
or  Incremental  translation  features  described  in  Sections  7-9. 

2.  Attempt  to  perform  translation  on  a dedicated  system.  Tests  have 
shown  that  running  multiple  processors  will  statistically  affect 
total  elapsed  time. 

1.6  Translation  Suninary 

Table  1-2  correlates  the  basic  translation  steps  with  the  Input/Output 
requirements  and  the  estimated  time  to  perform  each  step. 


1 man-day 


Write  61  levels 
for  source  database(s) 
and  run  IDS  Analyzer 

1 . MD  section  and 
61  levels 

1 . Source  SDDL 
Table 

1 man-day 

Write  61  levels 
and  MD  section  to 
target  database(s)  and 
run  IDS  Analyzer 

1.  MD  section  and 
61  levels 

1 . Target  SDDL 
Table 

2 man-days 
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Write  TDL  Description 
and  run  TDL  Analyzer 

1.  TDL  Description 

1.  TDL  Tables 
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Run  the  Restructurer 

1 . Source  RIF 

2.  TDL  tables 
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tables 

1 . Target  RIF 
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Run  the  Writer 

1.  Target  RIF 

2.  Target  SDDL 
tables 

3.  Target  MD 
section 

1 . Target  IDS 
database(s) 

1 machine  day 
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2.0  PREPARING  FOR  DATA  TRANSLATION 


This  section  describes  the  p re- translation  preparations  that  must  be 
completed  before  the  translation  specifications  (1 .e.  • 61  levels  and  TDL) 
can  be  written. 


2.1  RIF  Constructs 

The  Restructurer  accepts  only  databases  that  conform  to  the  rules  for 
Restructurer  Internal  Form  (RIF)  databases.  That  Is,  the  database  must  be 
a collection  of  records.  Records  are  made  up  of  Items,  and  are  related  by 
means  of  sets  (HsetN  Is  synonymous  with  the  IDS  term  "chain".  A set's 
owner  type  Is  the  chain  master,  and  the  member  type  Is  the  chain  detail). 
Certain  constructs  are  not  permitted  In  a RIF  database.  If  they  exist  In 
the  source  IDS  database,  their  resolution  Into  RIF  constructs  must  be 
specified  In  61  level  statements  added  to  the  MD  section.  The  use  of  61 
levels  Is  described  In  detail  In  Section  3 of  this  manual. 


Illegal  constructs  In  RIFs: 

1.  Sets  with  multiple  owner  and/or  member  types.  These  must  be 
resolved  Into  several  sets,  one  for  each  owner  type/member  type 
pair,  as  In  Figure  2-1. 

ILLEGAL  LEGAL 


Figure  2-1 

Resolution  of  Multiple  Owner-  and  Member-Type  Set 

Phantom  Chains.  These  are  user- Implemented  chains  whose  pointers 
are  IDS  reference  codes  stored  as  fields  In  the  master  and  detail 
records.  Such  chains  can  be  declared  In  61  level  statements  and 
Implemented  by  the  Reader  as  actual  sets  In  the  source  RIF. 


PERSON 


OCCUP-SET 


(CORRECT  CIRG) 


OCCUP-NAME 


Figure  2-2 
Resolution  of  a CIRG 


Natch-key  sets.  These  are  user- Implemented  sets  In  which  one  or 
more  Items  In  the  owner  and  member  record  types  are  declared  as 
natch-key  Items.  The  match-key  Items  In  the  member  record  type 
correspond  one-for-one  to  the  owner's  match-key  Items.  An  Instance 
of  the  match-key  set  consists  of  an  Instance  of  the  owner  record 
type  and  all  the  member  record  Instances  whose  match-key  Item 
values  are  equal  to  the  corresponding  match-key  Item  values  In 
the  owner  record.  Figure  2-3  gives  an  example  of  such  a set.  The 
STATE  record  Is  the  owner  type  and  the  PEOPLE  record,  the  member 


RESIDENCY 


type.  The  match- key  set  STATE -Of7 -RESIDENCE  Is  Implemented  by 
the  match-key  Items  NAME  In  the  STATE  record  and  RESIDENCY  In 
the  PEOPLE  record. 


Figure  2-3 
A Natch- Key  Set 

Match-key  sets  are  described  by  61  level  statements,  and  are 
constructed  by  the  Reader  In  the  source  RIF  as  explicit  sets. 


2.2  The  Restructurer's  Working  View  of  Databases 

During  the  construction  of  a database,  two  Important  tasks  must  be 
accomplished: 

a)  all  records  must  be  constructed  and  given  values  for  their  data 
Items,  and 

b)  all  sets  must  be  constructed. 

In  particular,  this  applies  to  the  construction  of  target  RIF  databases 
by  the  Restructurer.  Task  a)  Is  performed  In  a straightforward  way,  as 
directed  by  the  user's  TDL  descriptions.  The  Restructurer's  approach  to 
task  b)  Is  also  straightforward,  but  requires  that  the  user  understand  the 
concept  of  a set-significant  Item,  which  Is  described  In  the  remainder 
of  this  section. 


2.2.1  Set- significant  Items 

IDS,  as  well  as  all  modules  of  the  Data  Translator,  requires  that  If 
a record  type  Is  declared  a member  of  a set  which  Is  system-owned,  then 
every  Instance  of  the  record  type  must  be  a member  of  the  set.  Thus  no 
additional  effort  Is  required  to  establish  system-owned  sets.  When  a set 
Is  not  system-owned,  however,  some  means  (e.g.,  pointer  fields,  pointer 
arrays,  special  data  Items)  must  be  used  to  establish  whether  or  not  a 
given  Instance  of  the  member  record  type  belongs  to  the  set,  and  If  so,  to 
Identify  the  correct  owner  record  Instance. 

Ourlng  the  restructuring  phase  of  data  translation,  this  Is  accomplished 
by  storing  In  each  target  RIF  Instance  of  the  member  record  type,  a copy  of 
the  primary  key  of  the  corresponding  owner  record  Instance.  If  the  record 
Is  not  to  belong  to  the  set,  a suitable  null  string  Is  stored.  This  data 


NAME  POPULATION  CAPITOL  AREA 


STATE-OF-RESIDENCE 


resides  In  a collection  of  set-significant  Items  In  the  member  record  type. 
There  Is  one  set-significant  Item  for  each  data  Item  of  the  owner  record 
type's  primary  key.  The  primary  key  of  a record  type  Is  a collection  of 
data  Items  whose  values  uniquely  determine  any  Instance  of  the  record  type. 
More  detailed  Information  on  primary  keys  Is  given  In  Section  2.3.  A 
set-significant  Item  Is  said  to  be  significant  to  the  set  It  Is  used  to 

represent.  „ . t 

For  Instance,  consider  the  database  fragment  of  Figure  2-4  which 
represents  Information  about  presidents  of  the  US.  An  Instance  of  the 
HAS-NATIVE-PERSON  set  consists  of  a STATE  record  as  owner,  and  as  members, 
all  PRESIDENT  records  representing  presidents  born  In  that  state.  An 
Instance  of  the  HAD-AOMINISTRATION  set  consists  of  a PRESIDENT  record  as 
owner,  and  as  members,  all  ADMINISTRATION  records  representing  administra- 
tions headed  by  the  president.  The  Item  NAME<HAS-NATIVE-PERSON>  In  the 
PRESIDENT  record  Is  significant  to  the  HAS-NATIVE-PERSON  set,  while  the  Items 
LAST-NAME<HAD-AD> , FIRST-NAME<HAD-AD> , and  INITIAL<HAD-AD>  In  the  ADMINISTRA- 
TION record  are  significant  to  the  HAD-AOMINISTRATION  set.  Primary  key 
Items  are  underlined. 
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Figure  2-4 

Set-significant  Items 


Set-significant  Items  are  Identified  and  named  by  the  IDS  Analyzer, 
subject  to  the  following  rules: 

1.  Each  set-significant  Item  Is  significant  to  exactly  one  set. 

2.  The  Items  significant  to  a particular  set  are  In  one-to-one 
correspondence  with  the  Items  that  make  up  the  primary  key  of  the 
owner  record  type. 
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3.  Set-significant  Item  names  consist  of  the  owner  key  item  name 
followed  by  all  or  part  of  the  set  name  enclosed  In  angle 
brackets . 

Although  set-significant  Items  exist  only  In  the  target  RIF,  the  IDS 
Analyzer  Identifies  and  names  them  for  both  source  and  target  databases. 
This  helps  to  Insure  uniform  descriptions  for  user  databases  throughout 
the  data  translation  process,  and  the  source  set-significant  Items  may  be 
used  by  the  advanced  TDL  writer  as  If  they  existed  In  the  source  RIF. 


2.2.2  Augmented  Bachman  Diagrams 

At  every  stage  of  data  translation,  the  user's  chance  of  success  Is 
enhanced  significantly  by  the  use  of  carefully  drawn  Bachman  diagrams  to 
describe  source  and/or  target  data  structures.  Bachman  diagrams  used  to 
describe  source  and  target  RIFs  should  be  augmented  to  Include  all  set- 
significant  Items,  as  well  as  to  Indicate  which  data  Items  In  a record  make 
up  Its  primary  key,  and  which  set  a set-significant  Item  Is  used  to  establish. 
This  may  be  done  as  follows: 

1.  Augment  the  rectangles  representing  record  types  with  a rectangle 
whose  sides  are  dotted  lines. 

2.  Fill  the  new  rectangles  with  the  set-significant  item  names 
generated  by  the  IDS  Analyzer.  Keep  the  Items  significant  to  a 
particular  set  together  and  In  the  same  order  as  In  the  primary 
key  In  the  owner  record  type. 

3.  Draw  arrows  representing  sets  from  the  primary  key  item(s)  of  the 
owner  record  type  to  the  set-significant  1tem(s)  In  the  member 
record  type.  When  there  are  multiple  items  Involved,  horizontal 
braces  at  each  end  add  clarity. 


4.  Underline  each  record's  primary  key. 

Figure  2-4  Is  an  example  of  an  augmented  Bachman  diagram  drawn  In  this 
way.  It  should  be  emphasized  that  augmented  Bachman  diagrams  are  useful 
whenever  working  with  a source  or  target  RIF,  and  they  are  an  essential 
tool  In  writing  complex  TDL  descriptions.  They  are  also  a convenient  place 
In  which  to  record  set-significant  Item  names  after  they  are  generated  by 
the  IDS  Analyzer. 

As  a final  example.  Figure  2-5  shows  an  ordinary  Bachman  diagram  In 
which  all  primary  keys  have  been  underlined,  and  the  augmented  Bachman 
diagram  for  the  same  schema. 

U 2.3  Primary  Keys 

I.  The  Data  Translator  requires  that  a primary  key  be  specified  for  each 

record  type.  A primary  key  of  a record  type  Is  a collection  of  Items  whose 
!?  combined  values  uniquely  determine  any  Instance  of  the  record  type.  A 

record  type  may  have  many  possible  primary  keys,  but  exactly  one  must  be 
Identified  and  used  throughout  the  data  translation  process.  For  Instance, 
7 consider  the  record  shown  In  Figure  2-6.  The  Item  SOCIAL-SECURITY-NUMBER 
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Figure  2-5 
Football  Database 


Figure  2-5  (cont'd) 

Augmented  Bachman  Diagram  for  Football  Database 
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Figure  2-6 
A Record  Type 


could  be  used  as  a primary  key  for  EMPLOYEE  in  most  cases,  since  no  two 
people  can  have  the  same  social  security  number.  However,  if  the  data- 
base contains  EMPLOYEE  records  for  each  person’s  current  and  past  pay 
grade,  then  both  SOCIAL-SECURITY-NUMBER  and  RATE-OF-PAY  may  have  to  be 
declared  as  primary  key  items.  In  general,  LAST-NAME  alone  would  not  be 
an  adequate  primary  key,  though  in  some  cases  the  collection  LAST-NAME, 
INITIAL,  FIRST-NAME  would  serve  the  purpose.  Some  record  types  (e.g., 

CALC  records)  contain  a natural  choice  for  the  primary  key.  In  the  case 
of  a CALC  record,  it  would  be  the  item  used  as  the  hash  key.  However,  the 
Data  Translator  cannot  require  that  such  choices  be  made.  For  example. 

If  the  EMPLOYEE  record  of  Figure  2-6  Is  CALCed  on  SOCIAL-SECURITY-NUMBER, 
the  primary  key  of  EMPLOYEE  may  still  be  declared  to  be  FIRST-NAME, 
INITIAL,  LAST-NAME.  The  final  decision  depends  upon  the  user's  semantic 
knowledge  of  the  database. 

Some  records  cannot  be  completely  identified  by  data  that  actually 
resides  In  them.  (Link  records,  for  example,  may  not  contain  any  data 
items.)  Such  a record  can  be  identified  only  by  a combination  of  its  data 
items  and  set-significant  items  (corresponding  to  primary  keys  of  other 
records,  which  own  it  along  certain  sets).  Thus  set-significant  items, 
as  well  as  actual  data  Items,  may  participate  in  the  primary  key  of  a 
record  type.  This  situation  is  illustrated  in  Figure  2-7. 
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Figure  2-7 

Set-significant  Primary  Key  Items 


A STUDENT-COURSE-LINK  record  cannot  be  completely  identified  by 
TERM  and/or  GRADE,  since  during  a given  term  many  students  take  many 
courses,  and  many  receive  Bs.  However,  in  the  example  of  Figure  2-7,  it 
has  been  indicated  that  a STUDENT-COURSE-LINK  is  uniquely  determined  by 
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the  SS#  of  the  student  who  took  the  course,  tegether  with  the  course 
NUMBER  and  the  DEPARTMENT  that  gave  the  course.  If  students  are  permitted 
to  repeat  courses,  it  may  be  necessary  to  include  TERM  in  order  to  get 
an  adequate  primary  key. 

In  some  cases,  a set-significant  item  may  correspond  to  a primary 
key  item  in  the  owner  record  that  is  itself  set-significant.  Figure  2-8 
gives  an  example.  An  EMPLOYEE  is  identified  by  SS#,  and  a PROJECT  by 
by  the  DEPT  that  sponsors  it  and  the  SS#  of  its  leader.  There  is  one 
EMP-PROJ-LINK  record  for  each  employee  currently  working  for  each  project. 
The  use  of  a link  record  suggests  that  a project  may  employ  many  people, 
and  that  a person  may  work  on  several  projects  concurrently.  Thus,  to 
identify  an  EMP-PROJ-LINK  record,  one  must  know  the  employee's  SS#  as 
well  as  the  identity  of  the  project.  Accordingly,  all  three  set-signifi- 
cant items  in  the  EMP-PROJ-LINK  record  participate  in  its  primary  key.  A 
CONTRACT  record,  however,  is  uniquely  determined  by  its  CONTRACT#,  so  there 
is  no  need  to  specify  additional  primary  key  items. 
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Figure  2-8 

Set-significant  Items  that  Correspond  to 
Set-significant  Items 
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Set-significant  primary  key  data  is  declared  by  a 61  level  statement 
which  identifies  all  sets  whose  set-significant  Items  are  to  be  primary 
key  Items  In  the  member  record  type.  Notice  that  this  automatically 
enforces  the  following  restriction;  if  one  Item  significant  to  a particu- 
lar set  Is  also  a primary  key  Item,  then  all  other  Items  significant  to 
that  set  are  also  primary  key  Items. 

Primary  key  Identification  may  be  sumnarlzed  as  follows: 

1.  For  each  record  type,  a collection  of  data  Items  and  sets 
must  be  declared  as  participants  in  the  record's  primary  key. 

The  declared  data  items  and  the  Items  significant  to  the 
declared  sets  are  referred  to  as  the  record’s  primary  key 
items. 

2.  The  record  must  be  the  valid  member  type  for  each  set  type. 

3.  None  of  the  sets  may  be  system-owned. 

4.  The  combined  values  of  the  primary  key  Items  must  uniquely 
determine  an  Instance  of  the  record  type.  That  is,  any  two 
distinct  instances  of  the  record  type  must  differ  In  at  least 
one  primary  key  Item. 

5.  An  adequate  primary  key  can  always  be  Identified  for  records 
In  a valid  IDS  database  In  Its  RIF  configuration. 


A restructuring  transformation  is  complete  when  all  target  RIF 
record  Instances,  including  set-significant  data,  have  been  created.  In 
order  to  accomplish  this,  a Translation  Definition  Language  (TDL) 
description  of  the  transformation  must  be  written.  TDL  writing  will 
be  described  in  detail  In  Section  4 of  this  manual,  but  before  any  TDL 
statements  can  be  written,  certain  preparations  must  be  made.  These 
Include  checking  that  the  proposed  target  database  can  actually  be 
derived  from  the  source,  deciding  how  target  data  will  be  located  In 
the  source  database,  and  determining  selection  criteria  that  will  separate 
valid  candidates  for  target  records  from  Invalid  ones.  In  paragraphs 
2.4. 1-2.4. 3 this  process  Is  described  In  step-by-step  fashion. 


2.4.1 


1 - Materials  Required 


Bachman  diagrams  of  the  source  and  target  schemas  are  essential 
tools  to  the  process  of  restructuring  specification.  Idea  !1y»  they  should 
be  augmented  Bachman  diagrams,  showing  the  source  and  target  databases 
In  their  RIF  configuration,  complete  with  the  set-significant  Items 
identified  and  named  by  the  IDS  Analyzer.  However,  it  may  not  always  be 
possible  to  complete  the  61  level  additions  to  the  source  and  target  MD 
sections  and  obtain  a valid  IDS  Analyzer  run  before  drawing  up  preliminary 
restructuring  specifications.  When  this  Is  the  case,  augmented  diagrams 
should  still  be  used  with  set-significant  Items  named  by  the  user.  These 
will  be  replaced  by  actual  names  as  soon  as  the  IDS  Analyzer  can  be 
successfully  run. 


Figure  2-9 
Source  Database 


CONGLOMERATES 


2.4.2  Step  2 - Semantic  Validity  of  Proposed  Restructurl 


Restructuring  cannot  Introduce  new  Information  Into  a database. 
Rather,  during  restructuring  transformation.  Information  Is  retrieved 
from  Its  source  representation  and  stored  In  Its  target  representation. 
The  Information  Itself  does  not  change.  Thus,  for  a proposed  restruc- 
turing to  be  semantically  valid,  every  Instance  of  every  target  record 
type  must  exist  In  some  form  In  the  source  database.  Furthermore,  It 
must  be  distinguishable  from  other  sets  of  source  RIF  Instances  of  the 
same  form  which  would  not  be  valid  Instances  of  the  proposed  target 
record  type.  For  example,  consider  the  data  structures  shown  In  Figure 
2-9.  The  target  CONGLOMERATES,  COMPANIES,  EMP-LINK  and  BUILDINGS 
record  types  are  certainly  valid,  since  they  already  exist  as  source 
records.  The  target  PEOPLE  record  Is  valid,  provided  that  no  person  Is 
permitted  to  work  for  two  companies  controlled  by  different  conglomerates 
In  which  case  SS#  would  not  be  an  adequate  primary  key.  The  form  In 
which  PEOPLE  exists  In  the  source  Is  as  follows;  the  tree  In  Figure  2-10 
describes  a subschema  of  the  source  database  (non-dlrected  arrows  are 
used  since  the  Restructurer  traverses  sets  In  both  directions).  Any 
Instance  of  that  tree  defines  a target  PEOPLE  record  whose  SS#,  NAME, 
and  NET-WORTH  Items  are  taken  from  the  source  PEOPLE  record,  and  whose 
NAME<B0SS>  Item  Is  the  NAME  Item  from  the  source  CONGLOMERATES  record. 
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Figure  2-10 
A Source  Tree 


It  should  be  pointed  out  that  the  source  RIF  may  contain  multiple 
Instances  of  some  target  PEOPLE  records.  This  will  occur  whenever  a 
person  works  for  two  or  more  companies. 

The  target  PARENT  record  Is  also  valid,  but  Its  representation  In 
the  source  RIF  Is  slightly  less  obvious  than  that  of  PEOPLE.  Figure 
2-11  shows  what  may  be  considered  to  be  a tree  In  the  source  database. 
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PARENT-LINK 


PARENT-OF 


PEOPLE (PARENT) 


Figure  2-11 
A Source  "Tree 


! 


Strictly  speaking.  It  Is  not  a subschema  of  the  source  database,  but  It 
could  be  called  a sub- structure.  That  Is,  given  a collection  of  Instances 
of  the  source  schema,  one  can  pick  out  all  of  those  that  conform  to  the 
structure  of  Figure  2-11.  An  Instance  of  the  Figure  2-11  structure 
consists  of  a PEOPLE  record  Instance  (designated  the  "KID"),  a PARENT-LINK 
record  owned  by  the  KID  along  CHILD-OF,  and  a PEOPLE  record  Instance  (the 
PARPirri  that,  owns  the  PARENT-LINK  along  PARENT-OF.  Such  a trio  represents 
a target  PARENT  as  follows:  NAME  and  SS#  are  the  Items  of  the  same  name 
from  the  source  PEOPLE  Instance  designated  PARENT,  and  the  SS#<PARENTS>  Is 
the  KID’S  SS#.  In  this  case,  the  source  database  contains  exactly  on* 
Instance  of  each  target  PARENT. 

The  target  BLDG-LINK  record  Is  probably  not  valid,  however.  Given 
a PEOPLE  record,  one  can  locate  all  the  BUILDINGS  owned  by  companies  for 
which  the  employee  works,  but  It  Is  Impossible  to  distinguish  buildings 
In  which  the  employee  actually  works  from  the  others  owned  by  the  same 
company.  That  Is,  the  Information  to  be  represented  by  the  BLDG-LINK  record 
Is  not  represented  anywhere  In  the  source  database. 
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2.4.3 


3 - Feasibility  of  Proposed  Restructure 


The  Restructurer  Is  not  able  to  perform  all  semantically  valid 
restructuring  transformations.  It  requires  that  target  record  types 
be  represented  In  the  source  database  as  Instances  of  hierarchical 
substructures.  Specifically,  they  are  to  be  Instances  of  trees  of  the 
type  discussed  In  Section  2.4.2.  Figure  2-12  gives  several  examples. 

If  no  source  record  type  appears  more  than  once  on  the  tree  (Figure 
2-12  a,  b,  and  c)  then  It  Is  a subschema  of  the  source  database.  When- 
ever a source  record  type  appears  more  than  once  on  a tree,  then  an 
Identifying  label  must  be  assigned  to  each  appearance.  For  Instance, 

In  Figure  2-12  d,  the  Identifiers  FIRST,  SECOND,  and  THIRD  have  been 
attached  to  the  three  appearances  of  record  type  A.  on  the  tree.  These 
Identifiers  are  necessary.  An  Instance  of  the  tree  2-1 2d  consists  of  an 
Instance  of  A (the  FIRST),  the  Instance  of  B that  owns  It  along  set  1, 
the  Instance  of  A (the  SECOND)  that  owns  It  along  set  2,  and  the  Instance 
of  A (the  THIRD)  that  owns  the  SECOND  along  set  2.  The  three  Instances 
of  A will.  In  general,  be  different,  and  references  to  them  in  restruc- 
turing specification  will  have  to  specify  the  Instance  of  Interest.  The 
Identifiers  are  often  conceptual  aids,  as  well,  when  they  describe  the 
role  that  a source  record  Instance  plays  In  the  structure  of  a target 
record  Instance.  This  Is  the  case  with  the  KID  and  PARENT  Identifiers 
In  Figures  2-11  and  2-16.  Figures  2-12e  and  f give  additional  examples 
of  the  use  of  identifiers. 

The  Translator  plares  two  additional  restrictions  on  the  representa- 
tions of  target  records  In  the  source  database.  First,  there  are  three 
allowable  representations  for  target  data  Items  In  source  trees: 

1.  The  Item  Is  the  same  In  both  source  and  target. 

2.  The  target  Item  Is  a function  of  a source  Item.  That  Is,  there 
must  be  an  algorithm  which  accepts  the  source  Item  value  as 
Input  and  produces  the  target  Item  value  as  output.  The  most 
common  examples  are  data  type  conversions:  a YEAR  Item  might 

be  an  Integer  In  the  source  and  a character  string  In  the  target, 
or  a PAY-RATE  Item  might  be  a character  string  In  the  source  and 
a floating-point  number  In  the  target.  A more  exotic  example 
might  be  a CODE-NAME  Item  for  which  the  code  has  changed, 
requiring  that  all  Gs  be  changed  to  Ts  and  all  Ws  to  Qs.  It 
should  also  be  observed  that  this  type  of  representation  pro- 
hibits multi-item  operations  such  as  sum,  max,  or  average. 

3.  The  Item  Is  a function  of  the  tree  Itself.  That  Is,  the  target 
item  has  the  same  value  for  every  instance  of  the  tree  in  the 
source  RIF.  An  example  of  this  Is  shown  In  Figure  2-15,  which 
will  be  described  shortly. 

The  second  additional  restriction  requires  that  the  criteria  used  to 
separate  valid  Instances  of  a tree  from  Invalid  ones  must  Involve  only 
comparisons  between  an  Item  on  the  tree  and  a constant  value  or  one  other 
Item  on  the  tree.  Comparisons  Involving  multi-item  computations,  such  as 
average,  are  not  permitted. 
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Step  3 may  be  summarized  as  follows: 

For  each  target  record  type*  construct  a collection  of  trees, 

each  with  the  following  properties: 

1.  It  Is  a substructure  of  the  source  database,  and  has  the 
SYSTEM  node  as  Its  root. 

2.  Every  Item  in  the  target  record  exists  as  an  Item  or 
function  of  an  Item  In  a node  on  the  tree,  or  as  a function 
of  the  tree  Itself. 

3.  Where  necessary,  there  Is  a set  of  comparisons  between 
Items  on  the  tree  and  constant  values  or  other  Items  on 
the  tree  so  that  all  Instances  of  the  tree  which  would 
produce  Invalid  or  undesirable  target  record  Instances 
will  fall  at  least  one  of  the  comparisons. 

4.  Finally,  each  valid  target  record  Instance  must  exist  as 
an  Instance  of  one  of  the  trees  and  pass  all  of  Its 
comparisons. 

If  step  3 can  be  accomplished,  then  the  desired  transformation  can 
be  performed  by  the  Data  Translator.  If  not,  the  transformation  Is 
beyond  the  Translator's  capabilities. 

For  example,  consider  Figure  2-13.  Suppose  the  database  2-1 3a  Is 
the  source,  and  2-1 3b  Is  the  target.  Then  trees.  Item  correspondences, 
and  qualification  criteria  to  accomplish  this  transformation  are  shown  In 
Figure  2-14.  On  the  other  hand.  If  we  reverse  the  roles  of  source  and 
target,  then  appropriate  trees.  Item  correspondences,  and  qualification 
criteria  are  shown  In  Figure  2-15.  Notice  that  In  each  tree  for  the 
target  KIDS  record,  the  Item  SEX  Is  a function  of  the  tree  Itself,  and 
not  of  any  Item  on  the  tree. 

As  a final  example.  Figure  2-16  shows  trees  to  accomplish  the 
restructuring  transformation  described  In  Section  2.4.2. 


jence  of  Translator  Steps 


We  are  now  In  a position  to  summarize  the  entire  process  of  Data 
Translation. 


Step  1. 


Decisions  regarding  RIF  constructs  and  primary  keys  are 
made  as  described  In  Sections  2.1  and  2.3.  These  are 
specified  In  61  level  statements  In  the  source  and  target 
MD  sections.  This  process  Is  described  In  Section  3.  The 
IDS  Analyzer  Is  run  to  produce  source  and  target  SOPI 
tables,  as  described  In  Section  5. 


Validity  and  feasibility  of  the  proposed  restructuring 
transformation  Is  verified  as  described  In  Section  2.4. 
The  trees  generated  by  this  process  are  transcribed  Into 
TDL  statements.  This  procedure  Is  the  subject  of  Section 
4.  The  TDL  Analyzer  Is  then  run  to  produce  TDL  tables, 
as  discussed  In  Section  6. 
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The  Reader  creates  the  source  RIF. 
In  Section  7. 


Its  use  Is  described 


The  Restructurer  creates  the  target  RIF. 
Restructurer  Is  discussed  In  Section  8. 
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The  Writer  creates  the  user's  target  database,  as  described 
In  Section  9. 
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Figure  2-16 
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3.0  AUGMENTING  THE  IDS  MD  WITH  LEVEL  61  INFORMATION 

In  order  to  perform  data  translation  between  a source  database  and  a 
target  database,  it  is  necessary  to  describe  to  the  Translator  the  character- 
istics of  the  databases.  Each  of  the  Translator  modules  requires  specific 
information  about  the  data  upon  which  it  is  executing.  As  deslqned,  the 
Translator  is  table-driven  in  Its  execution.  That  is,  from  a description 
of  the  source  and  target  databases,  and  guides  for  transforming  source  into 
target,  the  Translator  can  restructure  almost  any  sequential,  ISP  or  IDS 
database  into  a new  IDS  database.  What  the  user  must  provide  to  the  Trans- 
lator is  the  aforementioned  descriptions.  This  section  outlines  the  rules 
for  describing  the  source  and  target  database. 

The  basis  for  the  database  description  Is  an  IDS  MD  section.  This  is 
true  even  if  the  source  database(s)  to  be  described  is  of  the  sequential  or 
ISP  type.  For  source  IDS  databases,  the  IDS  MD  already  exists,  whereas  for 

source  sequential  and  ISP  databases,  as  well  as  the  target  IDS  database,  an 

IDS  MD  must  be  prepared.  The  user  is  referred  to  the  IDS  Programmer's 
Guide  for  aid  in  preparation  of  the  MD  section. 

Once  the  MD  sections  have  been  written,  it  is  necessary  to  extend  them 

to  explicitly  provide  information  to  the  Translator  that  is  otherwise  un- 
obtainable. Specifically,  the  IDS  MD  does  not: 

1.  Identify  a record's  primary  keys  which  must  be  known  by  the 
Restructurer. 

2.  Identify  where  in  the  database  schema  entry  can  be  made  (location 
of  the  tops  of  the  database). 

3.  Identify  unusual  relations  implemented  without  the  use  of  IDS 
chains.  For  example,  phantom  pointers  must  be  explicitly  declared. 

4.  Identify  ISP  and  sequential  record  identifiers  that  are  required 
under  the  WWDMS  B-3,  T-l  and  T-2  implementations. 

In  addition  to  the  above,  the  user  must  restate  some  information  that  appears 
already  to  be  In  the  IDS  MD.  This  restatement  is  required  because  of  the 
algorithm  used  by  the  Translator  to  get  information  from  the  MD  to  its 
internal  data  description  tables  (SDDL  tables).  Section  3.1  details  the 
process  of  extending  the  IDS  MD. 

3.1  Process  of  Extending  the  IDS  MD  Section 

To  understand  the  rationale  for  extending  the  IDS  MD  It  Is  necessary  to 
be  aware  of  the  implementation  of  the  IDS  Analyzer.  Briefly,  the  IDS  MD 
section  with  extensions  Is  passed  to  the  IDS  Translator  (the  Honeywell  compiler) 
which  is  run  In  query  mode.  The  resultant  output  is  the  IDS  Query  dictionary 
whose  format  is  known.  Using  the  IDS  Query  dictionary  as  input,  the  IDS 
Analyzer  produces  SDDL  tables.  The  user  Is  referred  to  the  IDS  Data  Query 
Installation  Guide  for  a complete  description  of  the  layout  of  the  Query 
dictionary.  It  can  be  seen  from  the  diagram  of  the  dictionary  schema  in  that 
document  that  Information  above  and  beyond  the  normal  01,  02  and  98  level 
entries  of  an  MD  section  can  be  stored  within  the  Validation  and  Description 
records.  Figure  3-1  is  an  overview  of  the  MD  extension  process. 


Figure  3-1 

Extension  of  an  IDS  MD 


"Used"  Portions  of  the  Query  Dictionary 
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Refer  to  Figure  3-2  to  further  examine  the  algorithm  of  conversion 
between  MD  section  and  SDDL  tables.  The  diagram  Is  a subset  of  the  entire 
Query  dictionary  schema.  Only  the  actual  records  used  by  the  IDS  Analyzer 
are  Indicated.  The  table  below  shows  how  information  required  In  the  SDDL 
tables  Is  derived  from  the  Query  dictionary. 

Derivable  from  which  Query  dictionary 
SDDL  table  Information  records 


1. 

Names  and  attributes  of  01 
records 

1. 

Record  definition 

2. 

Names  and  attributes  of  non-01 
records,  e.g.,  contalned-ln- 
repeatlng  groups 

2. 

Validation  and  description 

3. 

Names  and' attributes  of  02 
fields 

3. 

Field  definition 

4. 

Names  and  attributes  of  03-49 
fields 

4. 

Validation  and  description 

5. 

Primary  key  Information 

5. 

Description 

6. 

Match-key  and  phantom  pointer 
relations 

6. 

Description 

7. 

Record  Identifiers  for  sequen- 
tial and  ISP  files 

7. 

Description 

8. 

Relations  Implemented  through 
chains 

8. 

Master  definition  and  detail  defini- 
tion 

9. 

ISP  and  Sequential  file  rela- 
tions 

9. 

Master  definition  and  detail  defini- 
tion. 

As  can  be  seen  from  the  above  table,  obtaining  Information  from  only  the 
Record  definition.  Field  definition.  Master  definition  and  Detail  definition 
records  Is  insufficient  to  provide  all  the  data  to  the  SDDL  tables.  Valida- 
tion records  are  automatically  created  by  the  IDS  Translator  in  query  mode 
for  all  02-49  entries.  The  user,  therefore,  need  not  be  concerned  with 
explicit  creation  of  these  records.  However,  to  create  a description  record, 
the  user  must  code  a level  61  entry  In  the  IDS  MD.  Level  61  entries  form  the 
basis  of  all  extensions  to  the  MD  section. 

Hhen  coding  level  61  entries,  they  must  be  placed  within  the  MD  section 
In  accordance  with  the  rules  defined  by  the  IDS  Translator  In  query  mode  and 
the  IDS  Analyzer.  Complete  syntactical  rules  are  given  In  Section  3.2.  In 
general,  an  extended  MD  section  will  look  like  Figure  3-3.  Level  61  entries 
are  coded  beneath  the  02-49  field  or  group  entry  to  which  they  apply. 
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Figure  3-3 

A Generic  Extended  IDS  MD  Section 
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3.1.1  Further  Rationale  for  Level  61  Entries 

As  the  user  reads  further  Into  this  section,  it  is  probable  that  he 
will  feel  that  restructuring  operations  are  being  specified  on  the  source 
database  by  denoting  contained-in-repeating  groups,  phantom  pointers  and 
match-key  relations.  In  a sense,  it  Is  true  but  these  specifications  must 
be  performed  at  database  description  time  (l.e.,  writing  level  61s), 
otherwise  the  Restructures  when  executed,  will  not  be  aware  of  the  non- 
IDS  constructs  that  the  user  wishes  to  preserve.  Consider  it  from  the 
following  perspective.  The  Restructurer  uses  as  Input  not  the  source  data- 
base, but  a database  produced  by  the  Reader  in  which 

1.  all  contained- In-repeating  groups  in  the  source  user  database  are 
now  full-fledged  groups  in  the  source  Restructurer  database  (Source 
RIF). 

2.  all  match-key  and  phantom  pointer  relations  in  the  source  user 
database  are  represented  as  legitimate  sets  in  the  Source  RIF. 

If  the  Information  represented  by  contained-in-repeating  groups,  phantom 
pointers  and  match-key  relations  is  to  be  used  at  all  in  the  construction 
of  the  target  database,  it  must  be  Identified  by  writing  level  61  entries. 

3.1.2  Summary  of  Required  Extensions 
61  entries  must  be  prepared  for  the  following  elements  of  a 


Level 

database. 


1.  All  groups  must  have  their  primary  keys  identified. 

2.  All  contained-in-repeating  groups  must  be  denoted. 

3.  Any  match-key  or  phantom  relations  must  be  Identified  if  the 
user  desires  the  Information  represented  in  those  relations  to 
be  preserved. 

4.  ISP  and  Sequential  databases  must  have  an  item  identified  within 
each  record  type  as  the  item  containing  the  record  ID. 

5.  Items  whose  usage  Is  DISPLAY-1  or  DISPLAY-2  must  be  identified. 

6.  Repeating  groups  that  are  to  be  ignored  as  groups  must  be 
identified. 


3.2  Level  61  Rules 

Before  coding  any  extensions  to  the  IDS  MD  section,  certain  rules  and 
restrictions  placed  both  by  the  IDS  Analyzer  and  IDS  Translator  in  query 
mode  must  be  rigidly  obeyed.  These  rules  can  be  broken  down  Into  three 
categories  - global  rules  pertaining  to  the  IDS  MD  section,  global  rules 
pertaining  to  level  61  entries,  and  rules  concerning  automatic  generation 
of  names  by  the  IDS  Analyzer.  These  rules  are  described  below. 


I 


3.2.1  Global  MD  Section  Rules 


1.  Before  making  any  extensions,  the  IOS  HO  section  prepared  must 
be  legal  and  error-free.  It  Is  a good  Idea  to  process  the  MD 
section  by  the  IDS  Translator  (not  In  query  mode)  and  by  COBOL 
to  determine  If  It  Is  Indeed  syntactically  and  semantically 
correct.  A dummy  COBOL-IDS  program  with  a PROCEDURE-DIVISION 
of  only  a STOP  RUN  is  Ideal  for  this  purpose. 

2.  All  non-el ementary  item  entries  within  the  MD  section  must  have 
a SIZE  clause  on  them.  For  example,  the  MD  section  on  the 
left  below  must  be  changed  to  the  MD  section  on  the  right. 


02  GROUP-NAME. 

03  SUB-GROUP-NAME. 

04  ITEM-1  PIC  XX. 
04  ITEM- 2 PIC  XX. 
02  ITEM-NAME  PIC  XX. 


02  GROUP-NAME  SIZE  4. 

03  SUB-GROUP-NAME  SIZE  4. 
04  ITEM-1  PIC  XX. 

04  ITEM-2  PIC  XX. 

02  ITEM-NAME  PIC  XX. 


To  compute  the  size  of  a group  in  COBOL  use  the  following  rules. 

a.  Single-precision  computational  items  require  precedinq 
slack  characters  so  that  they  start  on  a fullword  boundary. 

b.  Double-precision  computational  items  require  preceding 
slack  characters  so  that  they  start  on  a doubleword 
boundary. 

c.  Non-computational  items  never  require  preceding  slack 
characters  unless  they  are  synchronized. 

d.  If  the  first  item  of  the  group  is  a computational  item, 
then  any  required  preceding  slack  characters  are  not 
counted  as  part  of  the  size  of  the  group. 

e.  The  number  of  slack  characters  at  the  end  of  group 
occurrence  is  (if  the  group  has  an  OCCURS  clause): 


condition 

1)  group  has  no  computational 
items  within  it 

11)  group  has  at  least  one  single 
precision  computational  but 
no  double-precision  computa- 
tional items 


number  of  slack  characters 
at  end  of  group 

zero 

However  many  slack  characters 
needed  such  that  the  size  of 
one  occurrence  of  the  group 
is  evenly  divisible  by  6 
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111)  group  has  at  least  one  double- 
precision computational  Item 


However  many  slack  characters 
needed  such  that  the  size  of 
one  occurrence  of  the  group  Is 
evenly  divisible  by  12. 


f.  All  records  are  assumed  to  start  on  a doubleword  boundary. 

3.  If  an  OCCURS  and  a SIZE  clause  are  coded  on  the  same  entry,  the 
OCCURS  clause  must  come  first. 


RIGHT 

03  GROUP-NAME  OCCURS  2 TIMES 
SIZE  18. 


WRONG 

GROUP -NAME  SIZE  18 

OCCURS  2 TIMES. 


If  a PICTURE  and  an  OCCURS  clause  are  coded  on  the  same  entry,  the 
PICTURE  clause  must  precede  the  OCCURS  clause. 


RIGHT 


WRONG 


03  REPEATING- ITEM  PIC  X(5)  03  REPEATING-ITEM  OCCURS  3 TIMES 

OCCURS  3 TIMES.  PIC  X(5). 

Note  that  "5"  is  the  length  (size)  of  one  occurrence  of  REPEATING- 
ITEM. 

5.  A PICTURE  and  a SIZE  clause  cannot  be  coded  on  the  same  entry. 

WRONG 

03  REPEATING- ITEM  PIC  X(6)  OCCURS  2 TIMES  SIZE  12. 

6.  It  is  highly  advisable  to  ensure  that  within  one  MD  section  all 
item  (level  03-49),  record  and  chain  names  are  unique.  This  is 
more  restrictive  than  absolutely  necessary,  but  if  non-unique 
item  names  are  present,  the  IDS  Translator  in  query  mode  will 
append  a letter  to  the  end  of  the  name  to  make  it  unique.  This 
adds  an  unnecessary  level  of  indirection  between  the  user's 
names  and  those  names  used  by  the  Data  Translator. 


NOT  RECOMMENDED 
02  FIRST-GROUP  SIZE  10. 
03  ITEM-1  PIC  XX. 
03  ITEM-2  PIC  X(8) 
02  SECOND-GROUP  SIZE  5. 
03  ITEM-1  PIC  XXX. 
03  ITEM-2  PIC  XX. 


RECOMMENDED 

02  FIRST-GROUP  SIZE  10. 

03  ITEM-1 -FG  PIC  XX. 
03  ITEM-2-FG  PIC  X(8). 
02  SECOND-GROUP  SIZE  5. 

03  ITEM-1 -SG  PIC  XXX. 
03  ITEM-2-SG  PIC  XX. 


7.  Every  01  record  must  have  as  one  of  its  02  fields  an  entry  exactly 
like:  "02  TRANSLATION-INFORMATION  SIZE  0",  or  abbreviated: 

"02  T-I  SIZE  0".  Beneath  this  02  entry  will  be  all  primary  key 
and  relation  Information  that  must  be  added  to  the  IDS  MD  section. 
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8.  No  group  may  have  more  than  sixty  Items  defined  for  it. 

9.  No  item  may  be  of  a length  greater  than  255  characters. 

10.  No  more  than  twenty  records  may  be  details  on  a given  chain,  e.g., 
if  record  A is  the  master  of  chain  X as  shown,  only  up  to  twenty 
record  types  may  be  a detail  on  that  chain.  Note  that  this  rule 
applies  to  record  types , not  instances. 


RECORD  A 


CHAIN  X 


RECORD  B 


RECORD  U 


Ninety  five  (95)  record  types  and  five  (5)  databases  are  the 
maximum  allowable  In  any  one  extended  IDS  HD  section  (see  Section 
3.8). 

User  names  may  not  be  TDL  reserved  words.  This  is  due  to  the 
parsing  restrictions  of  the  TDL  Analyzer.  The  reserved  word  list 
includes: 


ACCEPT 

ID 

OWNER/MEMBER 

ACCESS 

IF 

QUALIFIED 

ACTUAL 

IN 

RECORD 

ALL 

IS 

RESECT 

ARE 

LE 

SELECT 

AS 

LITERALLY 

SET 

ASSIGN 

LT 

SIGNIFICANT 

BY 

MACRO 

SOURCE 

CONVERT 

MEMBER/OWNER 

TARGET 

DATA 

NAME 

TDLAP 

EOF 

NAMES 

TO 

EQ 

NE 

VALUE 

FROM 

NULL 

VIA 

GE 

ORDER 

WHEN 

GT 

OTHER 

WITH 

' 01 


3.2.2  Global  Level  61  Rules 

1.  A level  61  entry  must  be  coded  beneath  02-49  entries  only.  In 
general  they  are  coded  directly  beneath  the  item  or  group  that 
they  are  intended  to  extend. 

2.  A level  61  entry  is  of  the  form  “61  text"  where  the  "61"  may 
start  no  further  left  than  column  12;  the  text  cannot  extend 
past  column  72. 

3.  There  must  be  at  least  one  Intervening  blank  between  "61"  and 
the  text. 

4.  The  maximum  length  of  any  61  level  text  is  24  characters.  Blanks 
preceding  the  beginning  of  the  text  are  not  counted  In  the  24 
character  limit  but  trailing  blanks  are.  Essentially,  this  makes 
every  61  level  entry  contain  exactly  24  characters.  If  the  user 
needs  to  code  a name  that  is  greater  than  24  characters,  two  61 
level  entries  are  required,  such  as: 


ITEM-NAME-THAT-IS-EXTRI 


r~ 


24th  character 


61  ELY 


5.  The  maximum  length  of  any  user  name,  group,  item  or  relation  is 
30  characters. 

6.  A comma  cannot  be  the  first  character  of  a level  61  entry. 

NOT  ALLOWED 
61  , text 

7.  When  processing  the  description  record  image  of  a level  61  entry, 
spaces  (blanks)  are  ignored  by  the  IDS  Analyzer.  Of  course  user 
names  cannot  have  intervening  spaces  within  them.  This  means  that 
if  a user  name  Is  to  be  split  over  two  level  61  lines,  the  first 
line  must  contain  exactly  24  characters  of  text. 

8.  The  legal  character  set  that  can  be  coded  within  a level  61  entry 
is  any  COBOL  character  with  the  exception  of  "+". 


3.2.3  IQS  Analyzer  Automatically-Generated  Names 

For  a variety  of  Implementation  reasons,  some  of  which  are  too  comolex 
for  this  document,  item  or  chain  names  as  specified  within  the  extended 
IDS  MD  section  are  altered  by  the  IDS  Analyzer.  Similarly,  it  Is  necessary 
to  create  names  for  Items  and  relations  so  that  certain  information  (which 
Is  not  supplied  by  the  user. ..a  convenience  feature)  Is  identified.  As  an 
example  of  the  former  case,  chains  which  have  multiple  detail  record  types 
(for  example:  chain- "HAS-CHILDREN"  with  "SONS"  and  "DAUGHTERS"  as  the  de- 
tail record  types)  are  transformed  Into  multiple  chains,  each  with  one 
detail  record  type  with  the  new  chain  names  being  slight  extensions  to  the 
original  (see  rule  #1).  In  the  second  case  above,  the  relation  between  a 
group  and  a contained- in- repeating  group  Is  never  explicitly  declared  by  the 
user  but  is  Instead  generated  by  the  IDS  Analyzer  (see  rule  #3). 


the  user  must  be  aware  of  how  the  IDS  Analyzer  will  alter, 
e names.  If  the  user  wishes  to  refer  to  a name  within  a 
the  actual  character-string  to  use  must  be  the  IDS  Analyzer 
ed  name.  The  examples  following  this  section  will  make 


. IDS  allows  multiple  detail  record  types  per  chain  type.  This 
Implies  that  one  relation  name  Is  used  from  the  master  record 
to  all  of  its  detail  record  types  on  a particular  chain  type. 
However,  the  Data  Translator  requires  that  each  (master  record, 
detail  record)  tuple  that  Is  related  have  a unique  relation  name. 
This  necessitates  slight  modification  to  the  chain  name  according 
to  the  following  rule: 

a)  The  chain  name  from  the  master  record  to  its  detail  record 
types  Is  appended  with  the  characters  "/char"  where  "char" 
is  a number  1-9,  or  a letter  A-K. 

b)  If  the  chain  name  is  greater  than  28  characters  only  the 
first  28  characters  are  used. 

c)  The  assignment  of  the  tack  on  "/char"  value  is  based  on 
reading  the  IDS  MD  section  top  to  bottom,  e.g.,  the  first 
98  DETAIL  entry  for  that  chain  will  be  "/l",  the  second 
will  be  '72*' , etc. 

Example 


98  SUPER-CHAIN  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER 
01  REC-2  ... 


98  SUPER-CHAIN  CHAIN  DETAIL  SELECT  CURRENT  MASTER 
01  REC-3  . . . 


98  SUPER-CHAIN  CHAIN  DETAIL  SELECT  CURRENT  MASTER. 
Will  generate  the  following  two  relation  names: 


RELATION 


MASTER 


DETAIL 


SUPER-CHAIN/1 

SUPER-CHAIN/2 


REC-1 

REC-1 


REC 

REC 


2.  If  a repeating  Item  Is  to  be  expanded  out  of  its  containing 

record,  then  the  resultant  group  name  is  the  name  of  the  original 
item,  and  the  sole  item  of  the  new  group  has  as  its  name  one  of 
the  following: 


r ■rttttfi  ir  rlfciii  mifi  (\  nUlTiiti 


U 


Li 


0 

8 


a)  The  original  item  name  appended  with  "/IT". 

b)  The  first  27  characters  of  the  original  item  name  appended 
with  "/IT"  if  the  original  name  was  longer  than  27  characters. 


Example 


Suppose  the  MD  section  is  as  follows: 

01  RECORD-1  TYPE  IS  1 RETRIEVAL  VIA  ... 

02  GROUP-NAME  SIZE  40. 

03  REP-ITEM  PIC  X(5)  OCCURS  4 TIMES. 

03  ANOTHER-REPEATING-ELEMENTARY-I  PIC  X 00)  OCCURS  2 TIMES. 
02  ... 

If  both  of  the  03  entries  are  to  be  considered  as  contained-in- 
repeating  groups,  then  the  IDS  Analyzer  will  convert  the  schema 
represented  by  the  above  as  follows: 


ORIGINAL 

'RECORD-T 


CONVERTED 

'RECORDED 


REP- ITEM, 


ANOTHER-REPEATING-ELEMENTARY-I 


The  groups  each  will  have  a single  item  named  as  follows: 


GROUP  ITEM  NAME  LENGTH  OF  ITEM 

REP- ITEM  REP- ITEM/ IT  5 

ANOTHER-REPEATING-  ANOTHER-REPEATING  10 

ELEMENTARY- I ELEMENTAR/IT 

Note  that  RECORD-1  will  no  longer  contain  within  it  the  40  characters 
of  GROUP-NAME.  The  relation  between  RECORD-1  and  its  new  dependent 
groups  is  given  a name  according  to  rule  3 below. 

Since  all  relations  must  have  names,  the  relations  between  a group 
(record)  and  its  contained-in-repeating  groups  (termed  a concatenated 
relation)  must  be  given  names  by  the  IDS  Analyzer.  The  rule  for 
construction  of  such  names  is  as  follows: 

relation  = the  lesser  of  (the  containing  group  and  its  first  12 

characters)  concatenated  with  "/OWNS/"  concatenated  with 
the  lesser  of  (the  contained-in-repeating  group  name  and 
its  first  12  characters) 

Example 

Using  the  names  from  the  preceding  example,  the  relation  names 
that  are  assigned  between  RECORD-1  and  its  contained-in-repeating 
groups  are: 
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RELATION 

Between  RECORD- 1 and  REP- ITEM 

Between  RECORD- 1 and 
ANOTHER-REPEATING-ELEMENTARY-I 


RELATION-NAME 
RECORD-1 /OWNS/REP- ITEM 
RECORD-1 /OWNS/ANOTHER-REPE 


In  Section  2 of  this  User  Manual,  the  augmented  Bachman  diagram 
was  introduced  and  explained.  Since  these  diagrams  are  notable  for 
their  inclusion  of  set-significant  items,  it  is  necessary  to  identify 
and  describe  to  the  Data  Translator  their  presence.  However,  all  set- 
significant  items  are  automatically  created  by  the  IDS  Analyzer.  To 
briefly  review: 

A set-significant  item  for  a member  (detail)  record 
type  X is  created  for  every  primary  key  item  in  every  owner 
(master)  record  type  for  which  X is  a member  (detail).  Note 
that  set-significant  items  may  be  primary  key  items  and 
hence,  set-significant  items  can  be  created  from  set-signi- 
ficant items. 


4.  Set  significant  items,  described  in  Section  2 are  given  names  as 
follows: 

set-significant  item  name  = owner  key  item  name  concatenated  with 
"<relation  name  between  owner  and  member>" 

Note  that  if  the  owner  key  item  is  also  a set  significant  item, 
the  definition  of  item  name  generation  must  be  applied  recursively. 
There  is  a maximum  limit  of  240  characters  for  a set  significant 
item  name,  truncation  occurring  if  the  rule  causes  generation  of 
length  greater  than  240. 


Example 

Suppose  the  following  schema  exists: 


FIRST-RELATION 


with  key  item  "KEY-ITEM" 


REC0RD-X> 


SECOND-RELATION 


<Crecord-3> 


with  no  key  items 


with  no  key  items 


Primary  keys  for  RECORD-2  must  come  from  RECORD-1  and  primary 
keys  for  RECORD-3  must  come  from  RECORD-2.  The  keys  for  these 
records  (which  will  be  set-significant  Items)  will  have  the 
following  names. 


RECORD 

RECORD-2 

RECORD-3 


NAME  OF  SET-SIGNIFICANT  ITEM  (ALSO  A KEY) 
KEY - ITEM<  F I RST - RELAT 1 0N> 
KEY-ITEM<FIRST-RELATION><SECOND-RELATION> 


5.  System  entry  points  must  be  Identified  for  the  Data  Translator. 

A system  entry  point  is  defined  as  that  record  which  can  be 
considered  a detail  of  a record  thought  of  as  "SYSTEM".  The 
relation  between  the  "SYSTEM"  and  the  system  entry  point  record  is 
named  according  to  the  following  rules. 
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a)  only  CALC  and  PRIMARY  records  are  defined  to  be  system 
entry  points. 

b)  the  relation  name  Is  either 

"CALC-"  concatenated  with  the  system  entry  point  record 
name  (up  to  25  characters)  If  record  Is  CALC 


"PRIM-"  concatenated  with  the  system  entry  point  record 
name  (up  to  25  characters)  if  record  is  PRIMARY 


Example 

Assume  the  following  schema: 


RECORD-CALC 


PRIMARY 


LECORD- INVENTOR^ 


.RECORD-SEC- 1 


.RECORD-SEC-2 


System  entry  point  relations  will  be  generated  with  names: 
CALC-RECORD-CALC  and  PRIM-RECORD-INVENTORY 

3.2.4  Complete  Level  61  Syntax 

This  section  details  the  correct  syntax  for  all  features  of  the  level 
61  entries.  Specific  rules  and  examples  are  given  in  Sectiond  3.3  through 
3.6.  Standard  bracket,  brace,  double-bar  and  ellipsis  notation  is  used. 
Key  words  are  capitalized;  generic  user-names  are  in  lower  case.  Because 
coding  level  61  entries  can  be  tedious,  abbreviations  are  provided  for 
certain  key  words.  These  abbreviations  are  denoted  by  underscored 
characters.  For  example,  "PARENT"  can  be  abbreviated  as  "PA".  Strict 
attention  should  be  paid  to  the  use  of  the  comma,  colon,  semi-colon  and 
period  within  the  syntax  rules.  Each  separate  level  61  entry  (or  entity) 
is  denoted  by  a roman  numeral. 

Group  definition 

I.  61  OCCURS  integer  TIMES. 

II.  61  DO-NOT-RESTRUCTURE. 

III.  61  EOG. 
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Item  definition 
I.  61  ITEM- INFORMATION. 

II.  [61  PAD-CHARACTER;  'character'] 


DISPLAY 


■m 


Primary- key  definition 
I.  02  TRANSLATION^NFORMATION  SIZE  0. 

61  PRIMARY^KEYS. 

61  GROUP:  group-name-1, 

II  61  JTEMS:  i tern-name- 1 [, item-name-2] 

I 61  EXTERNAL-KEYS-FROM:  relation-name-1  [, relation-name-2]. . . 


61  GROUP:  group-name-2, 

61  HEMS:  Item-name-1  [, item-name-2]. . . 

61  EXTERNAL-KEYS-FROM:  relation-name-1  [, relation-name-2]. 


Rel ation-def i ni ti on 

I.  02  TRANSLATION^INFORMATION  SIZE  0. 
61  PHANTOM-POINTERS. 

61  RELATION:  relation-name-1 , 

61  DEPENDENT:  group-name-1, 

61  POINTER:  item-name-1 

61  ; RELATION:  rel ati on-name-2, 

61  DEPENDENT:  group-name-2, 

61  POINTER:  item-name-2 


02  TRANSLAT I ONMNFORMAT I ON  SIZE  0. 

61  MATCH-KEY-RELATIONS. 

61  PARENT:  group-name-1 

61  KEYS:  item-name-1  [, item-name- 2] , 

61  RELATION:  relation-name-1, 

61  DEPENDENT:  group-name-2, 

61  £EYS:  item-name-3  [, Item-name-4]. 
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61  ; PARENT:  group- name- 3, 

61  KEYS:  item -name -5  [,item-name-6]. . 

61  RELATION:  relation-name-2, 

61  DEPENDENT : group-name-4, 

61  KEYS:  item-name-7  [, Item-name-8]. . 


Sequential.  ISP  files 

I.  61  ITEM-INFORMATION. 

61  I DENT:  'character-string' 


3.3  Group  definition 

Within  any  01  record,  it  is  possible  to  have  not  only  Items,  but  also 
groups.  Identification  of  these  groups  and  an  indication  whether  or  not 
the  group  is  to  be  considered  a contained-ln-repeating  group  must  be  given 
to  the  IDS  Analyzer.  Use  of  the  following  level  61  entries  provides  this 
information. 

61  OCCURS  Integer  TIMES. 

61  EOG. 

61  D0-N0T- RESTRUCTURE. 

Rules: 

1.  Integer  must  be  a positive  integer. 

2.  Integer  must  be  exactly  equal  to  the  COBOL  OCCURS  Integer  TIMES 
on  the  immediately  preceding  02-49  entry. 

3.  Every  OCCURS  clause  coded  on  a 02-49  entry  must  have  a matching 
61  OCCURS  Integer  TIMES  entry  directly  following. 

4.  Every  61  OCCURS  integer  TIMES  entry  must  be  matched  by  a 61  EOG 
(end-of-group)  entry  to  be  placed  after  the  last  Item  of  the  group. 

5.  If  the  group  is  not  to  be  a contained-ln-repeating  group,  then 
61  DO-NOT-RESTROcTURE  must  immediately  follow  the  61  OCCURS 
Integer  TIMES  entry. 

6.  For  groups  whose  number  of  occurrences  is  one,  the  COBOL  OCCURS 
clause  need  not  be  coded.  Three  choices  are  available  to  the 
user. 

a)  Code  a 61  OCCURS  1 TIMES  - 61  EOG.  combination  after  the 
group  entry  and  after  the  last  Item  entry  within  the  group. 

This  will  cause  the  group  to  become  a contained-in-repeating 
group . 

b)  Code  a 61  DO-NOT-RESTRUCTURE  after  the  group  entry.  This 
will  cause  the  IDS  Analyzer  to  treat  the  group  as  a single 
item  made  up  of  the  concatenation  of  all  of  its  subordinate 
entries. 


- mnn 
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c)  Do  nothing.  The  IDS  Analyzer  will  treat  all  subordinate 
entries  as  Items  at  the  same  hierarchical  level  as  the  group. 
The  concept  of  a group  is  Ignored. 

7.  Contained- in- repeating  groups  may  be  defined  for  source  databases 
only. 

8.  Only  one  level  of  nesting  of  contained-ln-repeatlng  groups  is 
allowed.  Contained-in-repeating  groups  cannot  contain  their  own 
contained-in-repeating  groups. 


[Group  definition] 


Original  Schema 


UNIVERSE 


Desired  Trans la tor- viewed  Schema 


UNIVERSE 


Original  MD  Section 

01  UNIVERSE  TYPE  IS  1 ... 

02  UNIVERSE-NAME  PIC  X(10). 

02  CONTENTS  SIZE  80. 

03  GALAXIES  OCCURS  5 TIMES 
SIZE  80. 

04  GALAXY-NAME  PICX(IO). 
04  GALAXY-SIZE  PIC  9(6) 

02  INHABITED-BY  PIC  X(10). 


GALAXIES 


Required  Extended  MD  Section 

01  UNIVERSE  TYPE  IS  1 ... 

02  UNIVERSE-NAME  PIC  X(10). 

02  CONTENTS  SIZE  80. 

03  GALAXIES  OCCURS  5 TIMES 
SIZE  80. 

61  OCCURS  5 TIMES. 

04  GALAXY-NAME  PICX(IO), 
04  GALAXY -SIZE  PIC  9(6). 
61  EOG. 

02  INHABITED-BY  PIC  X(10). 


This  example  illustrates  the  simple  expansion  of  one  contained-in- 
repeating  group  from  its  contalned-in  group.  Note  that  all  groups  have  a 
SIZE  clause  on  their  entry.  The  61  OCCURS  5 TIMES  is  placed  immediately 
below  the  COBOL  OCCURS  clause  while  the  61  EOG.  Is  placed  after  the  last 
item  of  the  group. 

Because  a contained- in-repeating  group  was  defined,  a relation  name 
must  be  generated  between  UNIVERSE  and  GALAXIES.  Rule  3 In  Section  3.2.3 
states  that  the  relation  name  will  be  "UNIVERSE/OWNS/GALAXIES".  As  far 
as  the  Data  Translator  Is  concerned,  UNIVERSE  will  not  have  any  galaxy 
data  within  its  record. 
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[Group  definition] 

Origin*!  Schema 
( UNIVERSE  ) 


Original  HO  Section 

01  UNIVERSE  TYPE  IS  1 ... 

02  UNIVERSE-NAME  PIC  X(10). 

02  CONTENTS  SIZE  80. 

03  GALAXIES  OCCURS  5 TIMES 
SIZE  80. 

04  GALAXY-NAME  PIC  X(10). 
04  GALAXY-SIZE  PIC  9(6). 
02  INHABITANTS  PIC  X(10) 


Desired  Trans! a tor- viewed  Schema 
( UNIVERSE  ) 


Required  Extended  MD  Section 

01  UNIVERSE  TYPE  IS  1 ... 

02  UNI VERSE -NAME  PIC  X(10). 

02  CONTENTS  SIZE  80. 

03  GALAXIES  OCCURS  5 TIMES 
SIZE  80. 

61  OCCURS  5 TIMES. 

61  DO-NOT-RESTRUCTURE. 

04  GALAXY-NAME  PICX(IO). 
04  GALAXY -SIZE  PIC  9(6). 
61  EOG. 

02  INHABITANTS  PIC  X(10). 


In  this  example,  GALAXIES  plays  no  part  In  the  restructuring  to  the 
target  database  so  a contained- in-repeating  group  Is  not  desired.  As 
before,  the  61  OCCURS  - 61  EOG.  combination  must  be  coded  because  a COBOL 
OCCURS  clause  is  present.  The  61  DO-NOT-RESTRUCTURE  Is  placed  Immediately 
after  the  61  OCCURS  to  Indicate  to  the  IDS  Analyzer  that  GALAXIES  Is  not  a 
contalned-ln-repeatlng  group  but  Is  to  be  treated  as  a single,  elementary, 
item  of  alphanumeric  type  with  a length  of  80  characters. 


A 


[Group  definition] 


Desired  Translator-viewed  Schema 


ROCK-STARS 


ROCK-STARS 


IAND- PLAYED- IN 


VORITE-GROUP 


Original  HO  Section 


Required  Extended  HD  Section 


01  ROCK-STARS  TYPE  IS  20  ... 

02  STARS-NAME  PIC  X(20). 

02  BANOS  SIZE  100. 

03  BANDS-PLAYED-IN  PIC  X(20) 

OCCURS  5 TIMES 

02  FAVORITE-GROUPIE  SIZE  11. 

03  GROUPIE-NAME  PIC  X(10). 

03  GROUPIE-SEX  PIC  X. 


01  ROCK-STARS  TYPE  IS  20  ... 

02  STARS-NAME  PIC  X(20). 

02  BANDS  SIZE  100. 

03  BANDS-PLAYED-IN  PIC  X(20) 

OCCURS  5 TIMES 

61  OCCURS  5 TIMES. 

61  EOG. 

02  FAVORITE-GROUPIE  SIZE  11. 

61  OCCURS  1 TIMES. 

03  GROUPIE-NAME  PIC  X(10). 

03  GROUPIE-SEX  PIC  X. 

61  EOG. 


This  example  Illustrates  two  additional  methods  of  identifying 
contalned-ln-repeatlng  groups.  BANDS-PLAYED-IN  is  a repeating  item. 
FAVORITE-GROUPIE  Is  a group  that  occurs  only  once.  Note  that  for  repeating 
Items,  the  61  OCCURS  - 61  EOG.  combination  Is  placed  directly  beneath  the 
repeating  Item  entry.  Upon  completion  of  this  coding,  the  IDS  Analyzer 
will  create  the  following: 

GROUP  ITEMS 

ROCK-STARS  STARS-NAME 

BANDS-PLAYED-IN  BANDS-PLAYED-IN/ IT  (see  rule  2 In  Section  3.2.3) 

FAVORITE-GROUPIE  GROUPIE-NAME,  GROUPIE-SEX 


RELATIONS 

ROCK-STARS/OWNS/BANDS-PLAYED 

ROCK-STARS/OWNS/FAVORITE-GRO 
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[Group  definition] 


r 


Original  Schema 


Desired  Translator-viewed  Schema 


ROCK-STARS 


ROCK-STARS 


Original  MD  Section 

01  ROCK- STARS  TYPE  IS  20  ... 

02  STARS-NAME  PIC  X(20). 

02  BANDS  SIZE  100. 

03  BANDS-PLAYED-IN  PIC  X(20) 

OCCURS  5 TIMES. 

02  FAVORITE-GROUPIE  SIZE  11. 

03  GROUPIE-NAME  PIC  X(10). 

03  GROUPIE-SEX  PIC  X. 


Required  Extended  MD  Section 

01  ROCK-STARS  TYPE  IS  20  ... 

02  STARS-NAME  PIC  X(20). 

02  BANDS  SIZE  100. 

61  DO-NOT-RESTRUCTURE. 

03  BANDS-PLAYED-IN  PIC  X(20) 

OCCURS  5 TIMES. 

61  OCCURS  5 TIMES. 

61  EOG. 

02  FAVORITE-GROUPIE  SIZE  11. 

03  GROUPIE-NAME  PIC  X(10). 

03  GROUPIE-SEX  PIC  X. 


This  example  Illustrates  the  suppression  of  potential  contained-in- 
repeatl ng  groups.  Note  however,  that  the  61  OCCURS  - EOG.  combination  Is 
required  even  though  BANDS-PLAYED-IN  will  not  become  a group.  Upon 
processing  the  extended  MD  section  the  IDS  Analyzer  will  create  the 
following: 


GROUP 

ROCK-STARS 


ITEMS 

STARS-NAME,  BANDS,  GROUPIE-NAME,  GROUPIE-SEX 


s 4 
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3.4  Item  Definition 


Two  special  item  attributes  must  be  explicitly  described  to  the  Data 
Translator  via  the  IDS  Analyzer.  This  information  is  unavailable  through 
normal  means  within  the  Query  dictionary  and  hence  must  be  coded  on  level 
61  entries. 


61 

[61 


Rules: 


ITEM- INFORMATION. 
PAD-CHARACTER:  'character'] 


jjSl  DISPLAY:  Q 


1. 

2. 


3. 


Character  is  any  one  character  in  the  BCD  set. 

ITEM- INFORMATION  followed  optionally  by  PAD-CHARACTER  and  DISPLAY 
must  be  coded  directly  beneath  the  COBOL  elementary  item  for 
which  the  special  attributes  apply. 

PAD-CHARACTER:  'character'  clause  is  used  If  the  leading  or 
trailing  fill  characters  of  the  COBOL  Item  are  not  the  default 
blank  for  alphanumeric  and  zero  for  computational. 

DISPLAY:  Is  used  If 

the  COBOL  elementary  item  has  USAGE  DISPLAY-1  in  which  case 
DISPLAY :1  is  coded 

the  COBOL  elementary  item  has  USAGE  DISPLAY-2  in  which  case 
DISPLAYS  is  coded. 


a) 

b) 


0 


I a 


I) 


1 1 


1 M 


: r 
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[Item  definition] 


Original  Schema 


INVENTORY 


Desired  Translator-viewed  Schema 


INVENTORY 


Original  MD  Section 

01  INVENTORY  TYPE  IS  1 ... 

02  PART-NAME  PIC  X(10) 

USA6E  DISPLAY-2. 

02  PART-NUM  PIC  9(8)  USAGE  DISPLAY-1, 
02  PART-PRICE  PIC  9(6)  COMP-1 . 


Additional  information 

The  characters  before  the  first  digit 
in  PART-PRICE  are  always  asterisks 


Reguired  Extended  MD  Section 

01  INVENTORY  TYPE  IS  1 ... 

02  PART-NAME  PIC  X(10) 

USAGE-DISPLAY-2. 

61  ITEM-INFORMATION. 

61  DISPLAY: 2. 

02  PART-NUM  PIC  9(8)  USAGE  DISPLAY-1 
61  ITEM- INFORMATION. 

61  DIS : 1 . 

02  PART-PRICE  PIC  9(6)  COMP-1. 

61  ITEM- INFORMATION. 

61  PAD:'*'. 


This  example  is  a simple  illustration  of  the  placement  of  item  definition 
level  61  entries.  All  occurrences  of  the  61  DISPLAY  or  61  PAD-CHARACTER 
entries  must  follow  the  61  ITEM- INFORMAT I ON  entry. 


■ 


I l 

I . 


E 
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3.5  Primary  Key  Definition 


The  basis  for  the  Restructurer  algorithm  is  its  requirement  that  every 
source  and  target  group  have  primary  keys  within  it  such  that  each  instance 
of  a given  group  can  be  uniquely  identified  from  all  other  instances. 
Primary  keys  for  a group  can  come  from  either  or  both  of  two  sources. 

1.  A group  can  wholly  contain  all  item  within  it  such  that  Instances 
can  be  uniquely  identified.  CALC  records  are  good  examples  since 
the  fields  used  for  randomization  must  have  unique  values  for  each 
record  Instance. 

2.  Only  some  of  the  items  necessary  to  uniquely  identify  a group 
Instance  actually  reside  within  the  group.  The  remaining  key 
items  are  contained  in  the  owner  group(s). 


The  following  statements  provide  this  information. 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  PRIMARY^KEYS. 

61  GROUP:  group- name- 1 , 

|| 61  HEMS:  item-name-1  [, item-name-2]  ... 

I|61  EXTERNAL- KEYS- FROM:  relation-name-1  [, relation-name-2]  ... 


61  GROUP:  group-name-2, 

II 61  TTEMS:  item-name-1  [, item-name-2]  ... 

II  61  EXTERNAL ^KEYS-£R0M:  relation-name-1  [, relation-name-2]  ... 


Rules: 

1.  group-name-1,  group-name-2 must  be  groups  defined  within  the 

current  01  record  for  which  the  02  TRANSLATION-INFORMATION  appears. 
Specifically,  group-name-1  must  be  the  01  record  name  and  group- 
name-2.  . .group-name-n  must  be  contained- in-repeating  groups  owned 
by  group- name- 1 . 

2.  The  1 tern- name-1 .. . beneath  the  61  GROUP  entry  must  be  contained 
only  within  that  group. 

3.  The  relation-name-1,  relation-name-2...  immediately  following  61 
GROUP:  group-name-n  clause  must  be  one  of  the  following: 

a)  the  name  of  the  chain  for  which  group-name-n  is  a DETAIL  (see 
rule  1 in  Section  3.2.3  when  the  chain  name  is  modified). 

b)  the  name  of  the  concatenated  relation  generated  where  group- 
name-n  Is  a member  (see  rule  3,  Section  3.2.3). 

c)  the  name  of  a match-key  relation  for  which  group-name-n  is  a 
dependent. 

d)  the  name  of  a phantom  pointer  relation  for  which  group-name-n 
is  a dependent. 


13 

• • 

a 

* 4 

3 

a 


4.  Loops  or  cycles  of  primary  key  derivation  are  not  permitted. 

That  is,  if  the  arrows  represent  the  paths  where  primary  keys 
are  defined  via  the  EXTERNAL-KEYS-FROM  clause,  then  the  following 
illustrates  legal  and  Illegal  cases  of  this  rule. 


Legal 


Illegal 


Illegal 


Every  group  defined  by  the  user  must  have  primary  keys. 

Groups  at  the  "top"  of  a database,  e.g.,  those  groups  that  are 
not  details  of  any  non-CALC  chain  must  have  at  least  one  key 
item  and  all  of  its  key  items  must  be  present  within  that  group 
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[Primary  Key  definition] 


Original  Schema 


Desired  Translator-viewed  Schema 


I H 

) 1 

. i 

U l 

Bi 


3 

I 1 

3 

i K 


Original  MD  Section 

01  SHIP-TYPE  TYPE  IS  1 RETRIEVAL 
VIA  CALC  CHAIN. 

02  TYPE-NAME  PIC  X(20). 

98  CALC  CHAIN  DETAIL  RANDOMIZE  ON 
TYPE-NAME. 

98  SHIPS-WITHIN-CLASS  CHAIN  MASTER 
CHAIN-ORDER  AFTER. 

01  FLEETS  TYPE  IS  2 RETRIEVAL 
VIA  CALC  CHAIN. 

02  FLEET-DESG  PIC  X(40). 

98  CALC  CHAIN  DETAIL  RANDOMIZE  ON 
FLEET  DES6. 

98  ON-STATION-WITH  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

01  SHIPS  TYPE  IS  10  RETRIEVAL  VIA 
SHIPS-WITHIN-CLASS  CHAIN. 

02  SHIP-NAME  PIC  X(15). 

02  SHIP-SKIPPER  PIC  X(20). 

98  ON-STATION-WITH  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 

98  SHIPS-WITHIN-CLASS  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


Required  Extended  MD  Section 

01  SHIP-TYPE  TYPE  IS  1 RETRIEVAL 
VIA  CALC  CHAIN. 

02  TYPE-NAME  PIC  X(20). 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  PRIMARY-KEYS. 

61  GROUP:  SHIP-TYPE, 

61  ITEMS:  TYPE-NAME. 

98  CALC-CHAIN  DETAIL  RANDOMIZE  ON 
TYPE-NAME. 

98  SHIPS-WITHIN-CLASS  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

01  FLEETS  TYPE  IS  2 RETRIEVAL 
VIA  CALC  CHAIN. 

02  FLEET-DESG  PIC  X(40). 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K. 

61  G:  FLEETS, 

61  I:  FLEET-DESG. 

98  CALC  CHAIN  DETAIL  RANDOMIZE  ON 
FLEET  DESG. 

98  ON-STATION-WITH  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 


Original  MD  Section 


Required  extended  MD  Section 


01  SHIPS  TYPE  IS  10  RETRIEVAL  VIA 
SHIPS-WITHIN-CLASS  CHAIN. 

02  SHIP-NAME  PIC  X(15). 

02  SHIP-SKIPPER  PIC  X(20). 

02  T-I  SIZE  0. 

61  PRIMARY-KEYS. 

61  G:  SHIPS, 

61  I:  SHIP-NAME. 

61  E-K-F: 

61  SHIPS-WITHIN-CLASS. 

98  ON-STATION-WITH  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 

98  SHIPS-WITHIN-CLASS  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


Additional  Information 

The  SHIP-NAME  item  with  SHIPS  is  not  sufficient  to  identify  uniquely 
SHIPS  instances.  To  do  this  requires  knowing  what  type  a given  SHIP  is. 


This  example  shows  the  most  straight-forward  application  of  primary 
key  definition.  Since  FLEETS  and  SHIP-TYPE  are  CALC  records  they  are  by 
definition  uniquely  identified  by  their  randomize  fields.  SHIPS  is  a 
secondary  record  and  requires  the  inclusion  of  the  keys  from  one  of  its 
masters  to  uniquely  identify  a given  SHIPS  instance.  In  general,  there 
is  nothing  within  the  <1D  section  that  states  which  items  are  primary 
keys;  the  user  irjst  know  his/her  database  to  define  primary  keys.  Incorrect 
selection  of  primary  keys  will  generally  lead  to  incorrect  target  databases. 

Note  that  the  IDS  Analyzer  will  generate  two  set  significant  items 
for  the  SHIPS  record,  one  of  which  will  be  a primary  key.  These  are 
(according  to  rule  4 in  Section  3.2.3): 

FLEET-DESG<ON-STATION-WITH> 

TYPE-NAME<SHIPS-WITHIN-CLASS>  (primary  key) 


[Primary  key  definition] 


Original  Schema 


Desired  Translator-viewed  Schema 


1TERE0-SYSTEM! 


tereo-system: 


COMPONENTS 


Original  MD  section 

01  STEREO-SYSTEMS  TYPE  IS  1 ... 

02  OWNER-NAME  PIC  X(20). 

02  MADE-UP-OF  SIZE  90. 

03  COMPONENTS  OCCURS  5 TIMES 
SIZE  90. 

04  COMP-NAME  PIC  X(10). 

04  COMP-PRICE  PIC  9(6)  COMP-1 
02  BOUGHT-FROM  PIC  X(20). 


Required  Extended  MD  Section 

01  STEREO-SYSTEMS 

02  OWNER-NAME  PIC  X(20). 

02  MADE-UP-OF  SIZE  90. 

03  COMPONENTS  OCCURS  5 TIMES 
SIZE  90. 

61  OCCURS  5 TIMES 

04  COMP-NAME  PIC  X(10). 

04  COMP-PRICE  PIC  9(6)  COMP-1 
61  EOG. 

02  BOUGHT-FROM  PIC  X ( 20 ) . 

02  TRANSLATION- INFORMATION  SIZE  0. 

61  PRIMARY-KEYS. 

61  G:  STEREO-SYSTEMS, 

61  I:  OWNER-NAME. 

61  G:  COMPONENTS, 

61  I:  COMP-NAME. 

61  E-K-F: 

61  STEREO-SYSTE/OWNS/COMPON 
61  ENTS. 


This  example  illustrates  the  basic  principles  for  defining  primary  keys 
for  contained-in-repeating  groups.  Note  that  the  primary  key  of  COMPONENTS 
Is  the  combination  of  OWNER-NAME  and  COMP-NAME.  The  E-K-F  clause  uses  the 
IDS  Analyzer  generated  name  for  the  concatenated  realtion.  Finally,  observe 
that  the  size  of  COMPONENTS  group  is  90  which  is  not  5 x (10+6).  Two  slack 
characters  are  required  at  the  end  of  each  Instance  of  components  according 
to  rule  2 of  Section  3.2.1. 
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[Primary  key  definition] 


Original  Schema 


Desired  Translator-viewed  Schema 


HAS-STUDENTS 


y 


HAS-CLASSES 


( LINK-REC  j 


01 


Original  MO  Section 

LINK-REC  TYPE  IS  3 RETRIEVAL  VIA 
HAS-STUDENTS  CHAIN. 


98  HAS-STUDENTS  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


98  HAS-CLASSES  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


Reguired  extended  MD  Section 

01  LINK-REC  TYPE  IS  3 RETRIEVAL  VIA 
HAS-STUDENTS  CHAIN 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  G:  LINK-REC, 

61  E-K-F: 

61  HAS-STUDENTS: 

61  HAS-CLASSES. 


98  HAS-STUDENTS  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


98  HAS-CLASSES  CHAIN  DETAIL 
SELECT  CURRENT  MASTER. 


Many  IDS  databases  contain  relator  or  1 ink  records  between  two  record 
types.  A link  record  is  required  if  a relationship  exists  both  ways 
between  the  two  record  types.  This  example  illustrates  the  declaration 
of  primary  keys  for  a link  record.  Note  that  every  group  (record)  must 
have  primary  keys  even  If  it  does  not  contain  any  items.  In  this  case, 
the  primary  keys  of  LINK-REC  are  the  primary  keys  of  LINK-REC' s two  master 
record  types. 


[Primary  key  definition] 


Desired  Translator-viewed  Schema 


RESEARCHERS 


RESEARCHERS 


PROJECTS 


Required  Extended  MD  Section 

01  RESEARCHERS  TYPE  IS  1 RETRIEVAL  VIA 
CALC  CHAIN. 

02  RESEARCHER-NAME  PIC(30). 

02  PROJECTS-WORKED-ON  SIZE  50. 

03  PROJECTS  PIC  X(10)  OCCURS  5 

TIMES. 


Original  MD  Section 

01  RESEARCHERS  TYPE  IS  1 RETRIEVAL  VIA 
CALC  CHAIN. 

02  RESEARCHER-NAME  PIC  X(30). 

02  PROJECTS-WORKED-ON  SIZE  50. 

03  PROJECTS  PIC  X(10)  OCCURS  5 

TIMES. 


98  CALC  CHAIN  DETAIL  RANDOMIZE  ON  61  OCCURS  5 TIMES. 

RESEARCHER-NAME.  61  EQG 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  PRIMARY-KEYS. 

61  G:  RESEARCHERS, 

61  I:  RESEARCHER-NAME. 

61  G:  PROJECTS, 

61  I:  PROJECTS/ IT. 

61  E-K-F: 

61  RESEARCHERS/OWNS/PROJECT 

61  S. 

98  CALC  CHAIN  DETAIL  RANDOMIZE  ON 
RESEARCHER-NAME. 

In  this  example,  the  user  has  chosen  to  make  the  repeating  item  "PROJECTS" 
a group  for  restructuring  purposes.  Because  it  is  a group  It  must  have 
primary  keys  declared  for  It.  Assuming  that  more  than  one  RESEARCHER  could 
work  on  a given  project,  then  to  Identify  a PROJECTS  record  the  PROJECTS/IT 
item  and  keys  from  RESEARCHERS  (e.g.,  RESEARCHER-NAME)  is  required.  Note 
that  the  item  for  the  group  PROJECTS  Is  named  according  to  the  rules  in 
Section  3.2.3  (rule  #2). 


0 


3.6  Relation  Definition 

In  normal  IDS  databases,  relations  between  record  types  are  imple- 
mented via  the  98  CHAIN  MASTER  - CHAIN  DETAIL  combination.  The  IDS 
Analyzer  will  automatically  store  into  the  SDDL  tables  a relation  for 
every  CHAIN  MASTER  - CHAIN  DETAIL  pair  with  the  relation  name  the  same  as 
the  chain  name  (subject  to  rule  1 Section  3.2.3).  However,  because  IDS 
is  somewhat  restrictive  in  terms  of  legal  database  schemas,  certain  users 
have  implemented  new  relations  outside  the  bounds  or  knowledge  of  the  IDS 
software.  For  data  translation  purposes,  two  extraordinary  constructs 
used  to  implement  relations  can  be  defined  via  level  61  entries.  These 
constructs  are  match-key  relations  and  phantom  pointer  relations. 

3.6.1  Match-key  Relations 

Match-key  relations  exhibit  the  following  characteristics: 

1.  There  is  no  physical  implementation  of  the  relation  via  pointers. 
Instead,  the  relation  exists  between  two  record  types  if  the 
values  of  items  designated  as  the  "match-keys"  have  identical 
values. 

2.  One  record  type  of  the  relation  is  denoted  to  be  the  parent  and 
the  other  record  type  is  the  dependent  of  the  relation. 

3.  The  parent  and  dependent  record  types  may  be  the  same  record  type. 
That  is,  for  any  one  instance  of  that  record  type,  its  dependents 
are  all  other  record  instances  of  that  type  that  possess  the  same 
match-key  values  as  the  parent. 


02  TRANSLATION^NFORMATION  SIZE  0. 

61  MATCH- KEY-RELATIONS. 

61  PARENT:  group-name-1, 

61  KEYS:  item-name-1  [, item-name-2]  .. 
61  RELATION:  relation-name-1, 

61  DEPENDENT:  group-name-2, 

61  KEYS:  item- name-3  [,i tern- name -4]  ... 

61;  PARENT:  group-name-3, 

61  KEYS:  item-name-5  [, item-name-6]  .., 
61  RELATION:  relation-name-2, 

61  DEPENDENT:  group-name-4, 

61  KEYS:  item-name-7  [item-name-8]  ... 
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Rules: 

1.  MATCH-KEY-RELATIONS  must  have  as  its  immediately  preceding  0 L 
entry  "02  TRANSLATION-INFORMATION  SIZE  0".  In  general,  MATCH- 
KEY-RELATIONS  may  either  precede  or  follow  the  level  61  entries 
for  primary  keys  and  phantom  pointers. 

2.  group-name-1,  group-name-3,  etc.,  must  be  a groups  defined  within 
the  current  01  record  where  the  MATCH-KEY-RELATIONS  appears. 

This  restricts  the  parent  of  a match-key  relation  to  be  either 
the  01  record  name  or  a contained-in-repeating  group  defined 
within  the  current  01  record. 

3.  group-name-2,  group-name-4,  etc.,  may  be  any  group  within  the 
entire  level  61  extended  MD  section  and  is  designated  as  the 
dependent  of  the  relation. 

4.  relation-name-1,  relation-name-2,  etc.,  can  be  any  name  except 
for  chain  names  or  other  names  already  used  for  concatenated, 
phantom  pointer  or  match-key  relations. 

5.  item-name-1,  item-name-2,  etc.,  must  be  items  within  the  parent 
group. 

6.  item-name-3,  item-name-4,  etc.,  must  be  items  within  the  dependent 
group  of  the  relation. 

7.  The  number  and  type  of  the  items  in  the  parent  must  be  exactly 
the  same  as  those  of  the  dependent. 

8.  Multiple  match-key  relations  can  be  defined  within  the  same 
MATCH- KEY-RELATIONS  section  by  placing  a semicolon  after  the  last 
key  item  in  the  dependent  and  then  repeating  the  syntax  as 
specified. 

9.  Match-key  relations  cannot  be  de  defined  for  target  databases. 


61  PA:  CONGRESS-2, 

61  K:  CONGRESS-NUMB; 
61  R:  CONG-2-CONG-1 , 
61  D:  CONGRESS-1 
61  K:  CONG-NUM. 

98  ... 


This  Is  an  example  of  a basic  match-key  relation  application.  Two 
sections  of  the  database,  unlinked  by  chains,  are  to  be  related  through 
the  value  of  the  (CONG-NUM,  CONGRESS-NUMB)  tuple  of  key  values.  The  result 
of  this  description  to  the  Restructurer  will  be  no  different  than  if 
CONGRESS-1  and  CONGRESS-2  were  related  via  chains.  Note  that  the  level  61 
entries  for  CONGRESS-2  utilize  the  legal  MATCH-KEY-RELATIONS  abbreviations. 


[Natch-key  definition] 


Original  Schema 


Desired  Translator- viewed  Schema 


AIRCRAFT 


IUB- CONTRACTS 


SAME -CONTRACTOR 


AIRCRAFT 


IUB-CONTRACTOI 


MANUFACTURED-B 


S-CONTRACT 


Original  MO  Section 

01  AIRCRAFT  TYPE  IS  1 ... 

02  AIRCRAFT-NAME  PIC  X(20). 

02  CONTRACTOR  PIC  X(15). 

02  ALSO-MADE-BY  SIZE  200. 

03  S-CONTRACT  OCCURS  10  TIMES 
SIZE  200. 

04  SUB-CONTRACTOR-NAME 
PIC  X ( 20) - 


Required  Extended  MO  Section 

01  AIRCRAFT  TYPE  IS  1 ... 

02  AIRCRAFT-NAME  PIC  X(20). 

02  CONTRACTOR  PIC  X(15). 

02  ALSO-MADE-BY  SIZE  200. 

03  S-CONTRACT  OCCURS  10  TIMES 
SIZE  200. 

61  OCCURS  10  TIMES. 

04  SUB-CONTRACTOR-NAME 
PIC  X ( 20) . 

61  EOG. 

02  T-I  SIZE  0. 

61  P-K. 

61  6:  AIRCRAFT, 

61  I:  AIRCRAFT-NAME. 

61  G:  S-CONTRACT 

61  I:  SUB-CONTRACTOR-NAME. 

61  E-K-F: 

61  AIRCRAFT/OWNS/S-CONTRACT 


01  SUB-CONTRACTOR  TYPE  IS  2 
02  SUB-NAME  PIC  X(20). 
02  SUB-LOCALE  PIC  X(40) 


61  MATCH-KEY-RELATIONS 
61  PA:  AIRCRAFT, 

61  K:  CONTRACTOR; 

61  R:  SAME-CONTRACTOR 
61  0:  AIRCRAFT 


Original  MD  Section 


Required  Extended  MD  Section 
61  K:  CONTRACTOR; 

61  PA:  S-CONTRACT; 

61  K:  SUB-CONTRACTOR-NAME; 
61  R:  MANUFACTURED-BY; 

61  D:  SUB-CONTRACTOR, 

61  K:  SUB-NAME. 


01  SUB-CONTRACTOR  TYPE  IS  2 . . . 

02  SUB-NAME  PIC  X(20). 

02  SUB-LOCALE  PIC  X(40). 

02  TRANSLATION- INFORMATION  SIZE  0 
61  P-K. 

61  G:  SUB-CONTRACTOR, 

61  I:  SUB-NAME. 


This  complex  example  illustrates  the  method  for  coding  match-key 
relations  under  the  following  conditions: 

1.  Records  AIRCRAFT  and  SUB-CONTRACTOR  are  not  linked  together  by 
any  chains  or  other  relationships. 

2.  The  user  desires  that  all  AIRCRAFT  manufactured  by  the  same 
manufacturer  be  linked  together. 

3.  The  user  desires  that  the  repeating  information  within  AIRCRAFT 
on  sub-contractors  be  removed  from  AIRCRAFT  and  placed  into  its 
own  group.  Furthermore,  this  group  is  to  be  related  to  the 
SUB-CONTRACTOR  record  via  the  sub-contractor's  name. 

Note  In  the  example  that  several  things  must  be  accomplished  via  the  level 
61  entries. 

a)  Primary  keys  must,  as  always,  be  defined  for  all  groups. 

b)  The  contained-ln-repeating  group  S-CONTRACT  must  be  identified. 

c)  Match-key  relations  from  both  AIRCRAFT  and  S-CONTRACT  are 
stated  underneath  the  same  01  record  (e.g.,  AIRCRAFT). 


3.6.2  Phantom  Pointer  Relations 


Of  all  extraordinary  non-IDS  constructs  Implemented  by  the  user 
phantom  pointer  relations  are  the  most  difficult  to  describe  via  level 
61  entries.  A phantom  pointer  relation  is  restricted  to  the  following 
definition: 

1.  If  record  or  group  A possesses  a field  whose  value  is  that  of  a 
reference  code  to  record  or  group  B,  then  the  relationship 
defined  via  that  pointer  Is  termed  a phantom  pointer  relation. 

2.  A distinction  Is  made  between  a phantom  pointer  and  a phantom 
chain.  The  former  is  an  Implementation* of  a 1 :1  relation 
between  groups  A and  B while  the  latter  is  an  Implementation  of  a 
1 : n relation  between  group  A and  several  Instances  of  group  B. 
Phantom  Chains  are  not  implemented  as  a feature  of  the  Data 
translator  and  hence  cannot  be  described  via  level  61  entries. 

3.  For  all  purposes.  If  a pointer  within  group  A points  to  an 
instance  of  group  8,  the  relation  between  the  two  groups  has 
group  B as  owner  (or  parent)  and  group  A as  member  (or  dependent) 
This  is  the  exact  reverse  of  how  one  would  normally  regard  the 
relation. 

Suppose  the  following  Instance  schema  exists.  Group  A has  a 
phantom  pointer  to  group  B. 


instance, A 


Instance 


phantom 

pointer 


phantom 

pointer 


instance^ 


If  a relation  were  declared  to  have  A as  owner  and  B as  member, 
then  the  representation  of  this  relation  within  the  source  RIF 
database  would  violate  the  fundamental  law  of  network  databases. 

No  member  Instance  may  be  owned  along  the  same  relation  type  by 
more  than  one  Instance  of  a given  owner  group  type.  Because  of 
this  attribute  of  network  databases,  the  relation  must  be  viewed 
as  though  group  B were  the  owner  and  group  A the  member." 

Phantom  pointers  can  be  described  only  for  IDS  Source  databases. 


02  TRANSLATION^iNFORMATION  SIZE  0 
61  PHANTOM-POINTERS. 

61  RELATION:  relation-name-1 , 

61  DEPENDENT:  group-name- 1 , 

61  POINTER:  Item-name-1 
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61 

•.RELATION: 

relation-name-2, 

61 

DEPENDENT: 

group- name-2, 

61 

POINTER: 

item- name -2 

Rules: 

1.  The  PHANTOM- POINTERS  level  61  entries  must  appear  within  the 
02  TRANSLATION- INFORMATION  for  the  group  (record)  that  is 
considered  to  be  the  owner  (parent)  of  the  relation.  See  the 
#3  definition  of  a phantom  pointer  relation  above. 

2.  rel a ti on-name- 1 , relation-name-2,  etc.,  can  be  any  previously 
unused  chain  name,  concatenated  relation  name  or  match-key 
relation  name. 

3.  group-name-1,  group-name-2,  etc.,  must  be  the  name  of  the  group 
in  which  the  phantom  pointer  item  physically  resides.  The 
dependent  of  a phantom  pointer  relation  may  be  following: 


a)  the  same  group  type  as  the  parent. 

b)  a different  01  record  than  the  parent. 

c)  a contained- in- repea ting  group. 

4.  A contained-in-repeating  group  may  never  be  the  parent  (owner)  of 
a phantom  pointer  relation. 

5.  item-name-1,  item-name-2,  etc.,  must  be  single  precision  compu- 
tational-! items  within  the  dependent  group  specified  by  the 
immediately  preceding  61  DEPENDENT:  entry. 

6.  Phantom  pointers  can  be  defined  only  for  source  IDS  databases. 

7.  If  within  the  group  physically  containing  the  reference  code 
item,  that  item  is  zero,  then  no  relation  instance  between  the 
defined  parent  group  and  the  member  group  will  be  created. 
Restated,  all  values  of  Item-name-1,  item-name-2,  etc.  must  be 
either  zero  or  a legal  reference  code  of  the  parent  group  type. 


I 
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[Phantom-pointer  definition] 


k 


Original  Schema 


i 


( APPLIANCE  ) (MANUFACTURER^  Q APPLIANCE  L(^NUFACTURER^ 


Desired  Translator-viewed  Schema 
\ MAKES-APPLIANCES / 

+ 


phantom  pointer 


: 


Original  MD  Section 
01  APPLIANCE  TYPE  IS  1 ... 

02  APPLIANCE-NAME  PIC  X(30). 

02  REF-CODE-OF-MANUF  PIC  9(8)  C0MP-1. 
98  ... 

01  MANUFACTURER  TYPE  IS  2 ... 

02  MANUF-NAME  PIC  X(30). 

02  MANUF-CITY  PIC  X(15). 

98  ... 


Reguired  Extended  MD  Section 
01  APPLIANCE  TYPE  IS  1 ... 

02  APPLIANCE-NAME  PIC  X(30) 

02  REF-CODE-OF-MANUF  PIC  9(8)  COMP-1 . 
02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K. 

61  G:  APPLIANCE, 

61  I:  APPLIANCE-NAME. 

98  ... 

01  MANUFACTURER  TYPE  IS  2 ... 

02  MANUF-NAME  PIC  X(30). 

02  MANUF-CITY  PIC  X(15). 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K. 

61  G:  MANUFACTURER, 

61  I:  MANUF-NAME. 

61  PHANTOM-POINTERS. 

61  RELATION: 

61  MAKES-APPLIANCES, 

61  DEPENDENT: 

61  APPLIANCE, 

61  POINTER: 

61  REF-CODE-OF-MANUF. 


a 


98  ... 


In  this  basic  example  of  phantom  pointer  relations,  note  carefully 
that  despite  APPLIANCE  having  the  item  ( REF-CODE-OF-MANUF)  that  physically 
implements  a relation  from  APPLIANCE  to  MANUFACTURER,  the  user  must  code 
the  relation  with  owner/member  positions  reversed.  MANUFACTURER  is  the 
owner  of  MAKES-APPLIANCES  with  APPLIANCE  as  member.  Primary  keys  must  be 
defined  as  usual  for  all  groups. 
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[Phantom  pointer  definition] 


Desired  Translator-viewed  Schema 


ARITH-FUNCTIONS 


Vhantom  JP°1frters| 


CALCULATORS-WITH 


FUNCTION-KEY 


Requ i red  Extended  MO  Section 


Original  MD  Section 


01  CALCULATORS  TYPE  IS  1 ... 

02  MODEL-NAME  PIC  X(16). 

02  MANUF-NAME  PIC  X(20). 

02  HAS-FUNCTIONS  SIZE  300. 

03  FUNCTION-KEYS  OCCUR  50  TIMES 
SIZE  300. 

61  OCCURS  50  TIMES. 

04  REF-CODE -OF -ARITH-FUNCTIONS 
PIC  9(8)  COMP-1 . 

61  EOG. 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K 

61  G:  CALCULATORS, 

61  I:  MODEL -NAME. 

61  G:  FUNCTION-KEYS, 

61  I:  REF-CODE-OF-ARITH-FUN 
61  CTIONS. 

61  E-K-F: 

61  CALCULATORS/OWNS/FUNCTIO 
61  N-KEY 


01  CALCULATORS  TYPE  IS  1 ... 

02  MODEL-NAME  PIC  X(16). 

02  MANUF-NAME  PlC  X(20). 

02  HAS-FUNCTIONS  SIZE  300. 

03  FUNCTION-KEYS  OCCUR  50  TIMES 
SIZE  300. 

04  REF-CODE-OF-ARITH-FUNCTIONS 
PIC  9(8)  COMP-1. 


01  ARITH-FUNCTIONS  TYPE  IS  2 . 
02  FUNCTION-NAME  PIC  X(10) 


01  ARITH-FUNCTIONS  TYPE  IS  2 ... 

02  FUNCTION-NAME  PIC  X(10). 

■ 02  TRANSLATION-INFORMATION  SIZE  0 
61  P-K. 

61  G:  ARITH-FUNCTIONS, 


61  I:  FUNCTION-NAME. 

61  PHANTOM-POINTERS. 

61  R: 

161  CALCULATORS-HITH-FUNCTIO 
61  N. 

61  0:  FUNCTION-KEYS, 

61  PO: 

61  REF-CODE -OF - AR ITH- FUNCT I 
61  ONS. 

98  ... 

Frequently,  the  user  Implements  a set  of  phantom  pointers  within  a 
repeating  group  Inside  an  01  record.  To  preserve  this  relationship  as 
the  example  shows,  requires  first  that  the  contained-! n-repeatlng  group  be 
defined  within  CALCULATORS,  and  second,  that  the  phantom  pointer  relation 
be  denoted  within  the  owner (e.g.  ARITH-FUNCTIONS)  of  the  relation.  This 
Is  consistent  with  the  rules  of  phantom  pointer  definition  by  having 

•)  The  Npo1nted-toN  group  be  the  owner  of  the  relation. 

b)  The  "having  reference  code"  group  be  the  member  of  the  relation. 

Note  that  as  usual,  all  primary  keys  must  be  defined  for  every  group. 
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It  Is  a capability  of  the  Data  Translator  to  restructure  source  ISP 
and  sequential  databases  as  well  as  IDS  databases  Into  new  target  IDS 
databases.  To  do  this,  the  following  two  conditions  must  be  met: 


1.  The  sequential  or  ISP  database  must  conform  to  the  WWDMS  T-2 
requirement  that  every  record  type  have  a field  with  a constant 
value  (of  no  greater  than  12  characters)  that  Identifies  record 
Instances  to  be  of  a particular  type.  For  example,  an  INVENTORY 
record  would  have  a field  whose  value  was  always  "INVENTORY". 

2.  A description  of  the  source  ISP  or  sequential  database  must  be 
written  as  If  the  database  were  IDS,  e.g.,  an  IDS  MD  section  must 
be  prepared.  Furthermore,  this  MD  section  must  be  extended  or 
augmented  with  level  61  entries  according  to  the  rules  and 
examples  of  Section  3 of  the  User  Manual . 

Consider  condition  number  2.  Since  the  Translator  requires  SDDL 
tables  describing  all  user  databases,  and  since  the  only  method  by  which 
SDDL  tables  can  be  produced  Is  via  the  IDS  Analyzer  It  follows  that  a 
description  of  an  ISP  or  sequential  database  must  be  In  a form  usable  by 
the  IDS  Analyzer.  All  Input  to  the  IDS  Analyzer  must  be  an  extended  IDS 
MD  section. 

the  steps  required  to  produce  an  IDS  MD  section  are  simple  If  the 
user  keeps  one  thing  In  mind  - an  IDS  MD  section  stripped  of  Its  IDS 
peculiarities  (PAGE-RANGE,  ASCENDING- KEYS,  CHAIN-ORDER,  etc.)  is  a method 
of  writing  the  data  definition  of  a database  schema.  An  IDS  MD  section 
uses  the  concept  of  01  entries  to  Indicate  records,  02  entries  to  Indicate 
items  and  98  entries  to  designate  relations.  Clearly  an  ISP  or  sequential 
database  contains  records,  items  and  relations.  They  are  different  from 
IDS  only  In  their  physical  representation.  Hence  In  preparing  an  IDS  MD 
section  for  an  ISP  or  sequential  database,  use  the  fol1  .ules: 

1.  Indicate  records  with  an  IDS  01  entry. 

2.  Indicate  Items  with  IDS  02-49  entries. 

3.  Indicate  relations  with  a 98  chain  master  entry  for  the  parent 
of  the  relation,  and  a 98  chain  detail  for  the  dependent  of  the 
relation. 

A few  specific  restrictions  must  also  be  observed  to  Insure  correct 
processing  by  the  IDS  Analyzer. 

1.  Draw  a schema  diagram  of  the  ISP  or  sequential  database.  This 
diagram  must  be  of  a hierarchical  or  tree  structure.  Locate  the 
top  (or  root)  record  for  the  tree.  It  must  be  denoted  In  the 

MD  section  as  a CALC  CHAIN  DETAIL  record  Choose  any  Item  within 
the  record  to  be  the  randomize  field. 

2.  All  relations  are  given  a chain  name.  The  parent  record  of  the 
relation  must  contain  for  that  relation  the  following  entry: 


98  chain  name  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER. 


3.  All  other  IOS  HO  rules  must  be  followed.  They  Include  the 
following. 

a)  all  01  records  must  have  a TYPE  IS  and  a RETRIEVAL  VIA  clause 
Mhat  the  user  actually  writes  for  these  clauses  must  be 
acceptable  to  pass  the  IDS  Translator,  although  the  IDS 
Analyzer  will  Ignore  the  Information. 

b)  all  02-49  entries  must  have  either  a SIZE  clause  If  a group, 
or  a PICTURE  clause  If  an  Item. 

Once  the  IDS  NO  section  has  been  prepared,  all  of  the  extensions 
presented  In  the  preceding  part  of  this  section  In  the  User  Manual  must 


then  be  performed.  If  needed.  Additionally,  each  record  must  have  an 
Identifier  field  which  Is  prepared  according  to  the  rules  of  Section  3.7.1 
When  reading  any  of  the  rules  applying  to  level  61  entries,  the  references 
to  IDS  databases  should  be  considered  as  references  to  sequential  or  ISP 
databases. 


Example 

Suppose  an  ISP  database  exists  with  three  records  related  as  shown 
below.  PARTS  are  made  up  of  SUB-PARTS  and  machined  on  different  machines 


PARTS 


SUB-PARTS 


MACHINES 


An  IDS  MD  section  for  the  above  ISP  database  would  be  similar  to  the 
one  below. 

01  PARTS  TYPE  IS  1 RETRIEVAL  VIA  CALC  CHAIN. 

02  PARTS- ID  PIC  9(1)  VALUE  IS  1. 

02  PART-NAME  PIC  X(10). 


98  HAS-SUB-PARTS  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER 
98  MACHINED-ON  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER 
98  CALC  CHAIN  DETAIL  RANDOMIZE  ON  PART-NAME. 


01  SUB-PARTS  TYPE  IS  2 RETRIEVAL  VIA  HAS-SUB-PARTS  CHAIN 
02  SUB-PARTS- ID  PIC  9 VALUE  IS  2 
02  SUB-PART-NO  PIC  9(6). 


98  HAS-SUB-PARTS  CHAIN  DETAIL  SELECT  CURRENT  MASTER 


3-45 


01  MACHINES  TYPE  IS  3 RETRIEVAL  VIA  MACHINED-ON  CHAIN. 
02  MACHINES- IN  PIC  9 VALUE  IS  3. 

02  MACHINE-NO  PIC  9(4). 


98  MACHINED-ON  CHAIN  DETAIL  SELECT  CURRENT  MASTER. 

Note  that  the  PARTS- ID,  SUB-PARTS-ID,  and  MACHINES- ID  fields  Identify  their 
respective  record  types  and  must  be  followed  by  a 61  IDENT  entry. 


Identifier  Items  for  ISP  and  Sequential  Databases 

As  noted  previously  all  ISP  and  sequential  database  records  must  contain 
an  Item  that  has  a constant  value  for  all  Instances  of  a given  record  type. 
This  section  gives  the  rules  for  describing  this  Item  via  level  61  entries. 

ITEM-INFORMATION. 


61  IDENT:  'character  string' 

Rules 

1.  'character  string'  Is  a string  of  up  to  12  BCD  characters  enclosed 
by  single  quotes  that  Is  the  value  of  the  Item  which  Identifies 
the  record  for  which  these  entries  are  speclf.-d.  A single  quote 
cannot  be  one  of  the  BCD  characters. 

2.  The  two  level  61  entries  must  Immediately  follow  (In  order)  the 
02-49  entry  for  the  Item  that  serves  as  the  record  Identifier. 

3.  These  entries  must  be  specified  for  every  record  (not  contalned-in 
repeating  groups)  within  the  ISP  or  sequential  database  being 
described. 

4.  61  IDENT:  'characters  string'  cannot  appear  in  level  61  entries 
for  IDS  databases. 

5.  It  Is  assumed  that  'character-string'  Is  left-justified  within  the 
Item  in  the  record  Instance. 


[ISP  and  sequential] 


Original  Schema 


RESEARCHERS 


Desired  Translator-viewed  Schema 


RESEARCHERS 


Oriel nal  HD  Section  Required  Extended  HD  Section 

01  RESEARCHERS  TYPE  IS  1 RETRIEVAL  VIA  01  RESEARCHERS  TYPE  IS  1 RETRIEVAL  VIA 

CALC  CHAIN.  CALC-CHAIN. 

02  RESEARCH-ID  PIC  X(10).  02  RESEARCH- ID  PIC  X(10). 

02  RESEARCHER-NAME  PIC  X(20).  61  ITEM- INFORMATION. 

02  RESEARCHER-PHONE  PIC  9(7).  61  IDENT:  'RESEARCHER' 

96  CALC  CHAIN  DETAIL  RANDOMIZE  ON  02  RESEARCHER-NAME  PIC  X(20) 

RESEARCHER-PHONE.  02  resEARCHER-PHONE  PIC  9(7). 

02  TRANSLATION- INFORMATION  SIZE  0. 
61  P-K. 

61  6:  RESEARCHERS, 

61  I:  RESEARCHER-NAME. 

96  CALC  CHAIN  DETAIL  RANDOMIZE  ON 
RESEARCHER-PHONE. 

This  example  Is  of  a single  record  type  ISP  or  sequential  database. 

Every  RESEARCHERS  record  Instance  possesses  an  Item  whose  value  Is  always 
"RESEARCHER".  Note: 

1.  Because  RESEARCHERS  Is  at  the  top  of  the  schema.  It  must  be 
a CALC  CHAIN  DETAIL. 

2.  The  level  61  entries  for  ITEM- INFORMATION  and  IDENT  are  written 
Immediately  below  the  RESEARCH-ID  field  which  alweys  has  the  value 
"RESEARCHER". 

3.  Primary  keys  must  be  defined  as  usual. 


Another  feature  of  the  Data  Translator  Is  the  ability  to  combine 
multiple  source  databases  Into  multiple  target  databases.  This  section 
presents  the  technique  for  describing  multiple  databases. 

The  procedure  for  describing  multiple  databases  Is  simple.  Combine 
all  NO  sections  for  each  Individual  database  Into  one  file.  Consider  this 
to  be  one  large  MD  section  of  one  database  which  Is  broken  Into  sections. 
Combining  the  MD  sections  Is  necessary  because  only  one  SDDL  table  file  Is 
necessary  to  describe  all  source  databases  (similarly  for  target  databases) 
Hence,  only  one  IDS  Analyzer  run  Is  required  for  the  source  database(s) 
descriptions,  and  one  also  for  the  target. 

Some  additional  restrictions  must  also  be  observed. 

1.  Only  1-5  databases  may  be  combined. 

2.  All  chain,  record  and  03-49  level  Item  names  must  be  unique  across 
the  entire  combined  database  description. 


4.0  WRITING  TDL 

The  Translation  Definition  Language  (TDL)  Is  a language  In  which 
restructuring  specifications  nay  be  written  In  Translator-recognizable 
fora.  A complete  set  of  restructuring  specifications  written  In  TDL  Is 
referred  to  as  a TDL  description.  TDL  descriptions  are  encoded  Into 
TDL  tables  by  the  TDL  Analyzer.  The  Restructurer 's  construction  of  the 
target  RIF  Is  directed  by  the  contents  of  the  TDL  tables. 

In  Section  4 Is  described  the  process  by  which  the  preliminary 
restructuring  specifications  discussed  In  Section  2.4  can  be  converted 
Into  TDL  descriptions.  Section  4.1  describes  the  TDL  features  needed  to 
write  TDL  descriptions  for  any  set  of  preliminary  specifications  except 
those  Involving  complex  Itam  assignments  and  comparisons.  Section  4.2 
describes  several  advanced  TDL  features  which  can  save  the  experienced 
TDL  writer  time  and  effort.  It  also  describes  the  Interface  between  the 
Restructurer  and  user-written  qualification  and  conversion  routines  which 
are  needed  to  perform  the  complex  Item  assignments  and  comparisons  that 
cannot  be  done  directly  by  the  Restructurer.  Section  4.3  presents  a 
complete  TDL  syntax  summary. 

4.1  Basic  TDL  - Tree  Transcription 

The  central  task  In  TDL  writing  Is  nothing  more  than  the  translation 
of  the  trees.  Item  correspondences,  and  comparisons  described  In  Section 
2.4  Into  TDL  constructs.  Section  4.1.1  describes  a few  preliminaries 
used  to  communicate  with  the  TDL  Analyzer  as  well  as  human  readers  of  TDL 
descriptions.  Section  4.1.2  outlines  the  structure  of  TDL  descriptions, 
and  Sections  4.1.3-4.1.11  present  the  basic  TDL  statements. 


4.1.1  Preliminaries  - Comments.  Toggles,  Macros 

Comments  may  appear  anywhere  In  a TDL  description.  They  begin  with 
"/*"  and  end  with  For  example, 

i*  TDL  TO  TRANSLATE  FOOTBALL  DATABASE  */ 

Is  a valid  TDL  comment. 

The  TDL  Analyzer  recognizes  three  toggles  which  set  and  reset  TDL 
Analyzer  options.  They  are: 

L List  (causes  Input  lines  to  be  echoed) 

default«ON. 

A Analyze  (when  off,  allows  semantic  analysis  of  the  TDL 

description  without  actually  constructing  TDL  tables. 

■ It  Is  useful  for  finding  grammatical  errors  In  a TDL 
description).  defau1t*0N. 

D Dump  (causes  TDL  tables  to  be  dumped  at  the  end  of 

analysis.  TDL  Analyzer  dumps  are  In  a user  readable 
fpra.  See  Section  6 for  details).  default»OFF. 


“$"  sets  a toggle  OH,  "X"  turns  It  OFF.  Toggles  are  set  In  consents. 
For  example, 

f*  $0  XL  */ 

sets  Dump  OH  and  List  OFF.  This  Imposes  the  only  restriction  on  the  content 
of  consents:  If  they  contain  an  unintentional  "$L",  "XD",  etc.  surprising 
results  may  be  obtained. 

The  TDL  provides  a limited,  but  very  useful,  macro  facility.  A 
macro  statement  has  the  form: 

MACRO  <HAME>  LITERALLY  <LITERAL> 

<HAME>  can  be  any  character  string  that  Is  not  a TDL  reserved  word. 

<LITERAL>  Is  any  character  string  enclosed  In  single  quotes.  Common 
examples  Include: 

MACRO  SR  LITERALLY  'SOURCE  RECORD* 

MACRO  AV  LITERALLY  'ACCESS  VIA' 

MACRO  AT  LITERALLY  'ASSIGH  TO' 


* 1.2  TDL  Structure 

The  TDL  Is  a block-structured  language.  There  are  four  types  of 
t aments:  the  TARGET  RECORD  statement  which  consists  of  a header  and 
or  more  TDLAP  statements;  the  TDLAP  statement  which  consists  of  a 
Header  and  one  or  more  SOURCE  RECORD  statements;  the  SOURCE  RECORD  state- 
ment which  consists  of  a header  and  one  or  more  ITEM  statements  which  are 
Indivisible.  This  structure  Is  shown  in  Figure  4-1. 

TARGET  RECORD 
TDLAP 

SOURCE  RECORD 
ITEM 


SOURCE  RECORD 


TDLAP  * 


TARGET* RECORD 


Figure  4-1 
TDL  Block  Structure 
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Figure  4-2  1$  a reproduction  of  the  two  augmented  Bachman  diagrams 
of  Figure  2-13.  Figure  4-3  gives  a TDL  description  that  will  accomplish 
the  transformation  of  4-2a  Into  4-2b  described  by  the  trees  of  Figure 
2-14,  and  Figure  4-4  does  the  same  for  the  b-to-a  restructuring  of 
Figure  2-1S.  In  Figure  4-3  It  Is  assumed  that  the  TDL  description  has 
already  been  tested  for  grammatical  errors,  so  the  List  toggle  has  been 
turned  off,  while  Dump  Is  on  so  that  the  resulting  TDL  tables  can  be 
checked.  The  TDL  description  of  Figure  4-4  Is  assumed  to  be  freshly 
written,  so  that  the  A toggle  has  been  turned  off.  Note  the  use  of 
macros  In  Figure  4-4. 


4.1.3  TARGET  RECORD  Statement 

The  TARGET  RECORD  statement  Is  of  the  form: 

TARGET  RECORD  target- record-name 
[TDLAP  Statement]" 

The  notation  [...]"  Indicates  that  the  contents  of  the  brackets  are  to 
occur  at  least  m rftnes  and  no  more  than  n times.  If  n Is  not  a number 
but  a lowercase  unH,  then  the  contents  of  the  brackets  may  repeat  an 
arbitrary  number  of  times. 

There  Is  exactly  one  TARGET  RECORD  statement  for  each  target  record 
type.  In  It,  all  the  representations  of  the  target  record  In  the  source 
database  are  described.  The  TDLAP  statements  which  make  up  a TARGET 
RECORD  statement  describe  the  trees  used  to  represent  the  target  record 
In  the  source  database,  one  TDLAP  statement  per  tree.  TARGET  RECORD 
statements  begin  on  lines  3,  9,  and  18  of  Figure  4-3,  and  lines  7 and  12 
of  Figure  4-4. 


4.1.4  TDLAP  Statement 

The  TDLAP  statement  Is  of  the  form: 

TDLAP  tdlap-name  /'Integer's 
[target-item-name  •{  float  )]J! 

V. literal J 0 

[SOURCE  RECORD  Statement]" 

(Braces  - {•••}  - Indicate  that  exactly  one  of  the  objects  Inside  the 
braces  Is  to  be  chosen).  A TDLAP  (TDL  Access  Path)  statement  describes 
a tree  that  represents  a target  recoriMfype  In  the  source  RIF.  There  Is 
one  TDLAP  statement  for  each  of  the  trees  devel oped  In  step  3 of  Section 
2.4.  Each  tree  Is  assigned  a unique  tdlap-name,  which  may  be  one  to 
twelve  characters  In  length.  Examples  of  TDLAP  statements  begin  on 
lines  4,10,  and  19  of  Figure  4-3,  and  on  lines  8,  13,  and  20  of  Figure 
4-4.  The  trees  of  Figure  2-14  are  described  (In  order  of  appearance)  by 
the  TDLAPs  PARENT-PATH,  DAUGHTERS,  and  SON-FINDER  of  Figure  4-3.  The 
trees  of  Figure  2-15  are  described  (also  In  order)  by  the  TDLAPs  PARENT- 
PATH,  DAUGHTERS,  and  SONS  of  Figure  4-4. 


KIDDIES 


i NAMS<KIDOIES> 


Figure  4-2a 
A Database 


PARENTS 


DAUGHTER 


I NAME<SONS> 


I NAME<DAU> 


Figure  4-2b 
A Related  Database 


RESTRUCTURING  */ 

TARGET  RECORD  PARENTS 
TDLAP  PARENT-PATH 

SOURCE  RECORD  PARENTS  ACCESS  VIA  CALC- PAR 
ACTUAL  DATA  IN  ORDER 
OTHER  DATA  BY  NAME 
/*  DONE  WITH  PARENTS  */ 

TARGET  RECORD  DAUGHTER 
TDLAP  DAUGHTERS 

SOURCE  RECORD  PARENTS  ACCESS  VIA  CALC-PAR 
NAME  ASSIGN  TO  NAME<DAU> 

SOURCE  RECORD  KIDS  ACCESS  VIA  KIDDIES 
SEX  SELECT  IF  EQ  'FEMALE' 

NAME  ASSIGN  TO  NAME 
AGE  ASSIGN  TO  AGE 
/*  END  OF  DAUGHTER  */ 

TARGET  RECORD  SON 
TDLAP  SON-FINDER 

SOURCE  RECORD  PARENTS  ACCESS  VIA  CALC-PAR 
NAME  ASSIGN  TO  NAME<SONS> 

SOURCE  RECORD  KIDS  ACCESS  VIA  KIDDIES 
SEX  SELECT  IF  EQ  'MALE' 

NAME  ASSIGN  TO  NAME 
AGE  ASSIGN  TO  AGE 
/*  END  OF  SON  */ 

/*  TDL  DESCRIPTION  COMPLETE  7 
EOF 


4. 

5. 

6. 

7. 

8. 
9. 

10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 


Figure  4-3 
TDL  Example 
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The  values  of  target  items  which  are  constant  for  all  Instances  of  the 
tree  are  specified  next.  Such  Items  mav  be  assigned  Integer,  floating- 
point, or  literal  values,  as  In  lines  14  and  21  of  Figure  4-4,  Literals 
must  be  enclosed  In  single  quotes. 

Finally,  SOURCE  RECORD  statements  are  given.  These  statements 
specify  the  nodes  of  the  tree,  how  they  are  to  be  accessed,  which  compari- 
sons (if  any)  are  to  be  performed  on  their  Items,  and  how  their  data  Is  to 
be  used  to  construct  target  record  Instances.  Typically,  SOURCE  RECORD 
statements  make  up  the  bulk  of  a TDLAP  statement. 


4.1.5  SOURCE  RECORD  Statement 

The  SOURCE  RECORD  statement  has  the  basic  form: 

SOURCE  RECORD  source-record-name 
ACCESS  VIA  source-set-name 
[ITEM  Statement]^ 

This  is  not  the  complete  SOURCE  RECORD  statement  form.  Additional  features 
are  described  In  Sections  4.2.9  and  4.3.1. 

The  SOURCE  RECORD  statement  describes  a node  on  a tree,  "source-record- 
name"  is  the  name  of  the  source  record  type  which  appears  at  the  node, 
and  "source-set-name"  Is  the  name  of  the  source  set  which  connects  the 
node  to  its  parent  node  on  the  tree.  A parent  node  must  be  specified 
before  any  of  its  children  can  be  specified.  There  Is  exactly  one  SOURCE 
RECORD  statement  for  each  node  on  the  tree.  Examples  can  be  found  at 
lines  5,  11,  13,  20,  and  22  of  Figure  4-3,  and  lines  9,  15,  17,  22,  and 
24  of  Figure  4-4. 

The  ITEM  statement  takes  three  forms:  item  assignment,  comparison 
specification,  and  both  assignment  and  comparison  together.  These 
forms  are  described  In  the  next  three  sections. 


4.1.6  Item  Assignments 

The  Item  assignment  statement  specifies  the  correspondence  between  a 
source  Item  on  a tree  and  the  target  item  it  represents.  The  statement 
has  the  form: 

source-item-name  ASSIGN  TO  target -Item- name 

Examples  are  lines  12,  15,  16,  21,  24,  and  25  of  Figure  4-3,  and  16,  18 
19,  23,  25,  and  26  of  Figure  4-4.  This  statement  Is  adequate  for  target 
Items  which  are  exactly  equal  to  source  Items  on  the  tree,  and  those  which 
have  the  same  value  as  their  source  counterparts,  but  different  RIF  data 
types.  No  additional  effort  Is  required  to  accomplish  these  "Implicit" 
conversions,  since  each  Item's  RIF  data  type  (Integer,  floating-point,  or 
character)  and  pad  character  are  known  to  the  Translator.  A list  of 
these  conversions  appears  In  Figure  4-5.  Note  that  an  Integer- to-character 
or  floating-point- to-character  conversion  results  In  a right- justified 
character  string,  while  In  changing  a character  item's  length  or  pad 
character,  the  Item  Is  assumed  to  be  left-justified. 
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/*  TDL  DESCRIPTION  FOR  B TO  A RESTRUCTURING  */ 
/*  XA  */ 

MACRO  TR  LITERALLY  'TARGET  RECORD' 

MACRO  SR  LITERALLY  'SOURCE  RECORD* 

MACRO  AV  LITERALLY  'ACCESS  VIA* 

MACRO  IS  LITERALLY  'ASSIGN  TO' 

TR  PARENTS 
TDLAP  PARENT-PATH 
SR  PARENTS  AV  CALL-PAR 
ACTUAL  DATA  IN  ORDER 
OTHER  OATA  BY  NAME 
TR  KIDS 

TDLAP  DAUGHTERS 
SEX  - 'FEMALE' 

SR  PARENTS  AV  CALC-PAR 
NAME  IS  NAME<KIDDIES> 

SR  DAUGHTER  AV  DAUGHTERS 
NAME  IS  NAME 
AGE  IS  AGE 
TDLAP  SONS 
SEX  • 'MALE' 

SR  PARENTS  AV  CALC-PAR 
NAME  IS  NAME<KIDDIES> 

SR  SON  AV  SONS 
NAME  IS  NAME 
AGE  IS  A6E 
/*  ALL  DONE*/ 

EOF 


Source  I tea  Type  Target  Item  Type  Restrictions 
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All  otter  functions  which  convort  source  Items  to  target  Items  must 
be  performed  by  user-written  conversion  routines.  These  are  described  In 
Section  4.2.3. 

It  should  be  observed  that  set-significant  Items  are  assigned  In 
exactly  the  saw  way  as  actual  data  Itees  (lines  12  and  21  of  Figure  4-3 
and  lines  16  and  23  of  Figure  4-4). 

Finally,  under  certain  circumstances.  It  Is  possible  to  specify  the 
correspondence  of  a block  of  1 tarns  with  one  statement.  If  all  of  a target 
record's  actual  data  Itws  are  represented  by  Items  from  a single  source 
record,  and  furthermore.  If  the  source  and  target  record's  Items  correspond 
one-for-one  and  In  order,  then 

ACTUM.  DATA  IN  ORDER 

specifies  that  the  source  record's  data  Is  to  be  assigned  as  a block  to 
the  target  record's  data.  The  source  record  must  have  exactly  the  same 
number  of  Items  as  the  target  record,  they  must  correspond  In  order, 
corresponding  Items  must  have  Identical  lengths  and  pad  characters,  and 
the  actual  primary  key  Items  of  the  source  record  must  all  correspond  to 
actual  primary  key  Items  In  the  target  record,  and  vice  versa.  In  susmary, 
ACTUAL  DATA  IN  ORDER  may  be  used  If  the  source  and  target  records  are 
Identical  or  differ  only  In  their  set-significant  Items.  ACTUAL  DATA  IN 
ORDER  Is  used  at  line  6 of  Figure  4-3  and  line  10  of  Figure  4-4.  This 
feature  could  not  have  been  used  anywhere  else  In  Figures  4-3  and  4-4. 

Lines  7 of  Figure  4-3  and  11  of  Figure  4-4  appear  because  of  an 
unpleasant  anomaly  In  the  TDL  Analyzer  implementation.  If  ACTUAL  DATA  IN 
ORDER  Is  used.  It  must  be  the  first  item  statement  In  the  SOURCE  RECORD 
statement,  and  It  must  be  followed  by  at  least  one  other  Item  statement. 

Ir  general,  set-significant  Items  will  be  assigned,  or  qualification 
cr  trla  specified.  However,  some  transformations  will  require  the  use 
( em  statements  which  do  not  serve  any  purpose  besides  preventing  the 
E RECORD  statement  from  ending  with  ACTUAL  DATA  IN  ORDER.  OTHER  DATA 
ME  Is  useful  In  this  way,  provided  the  target  record  has  no  set- 
(flcant  Items,  as  In  the  examples  at  hand.  (For  a discussion  of  more 
c istructl ve  uses  of  OTHER  DATA  BY  NAME,  see  Section  4.2.2).  If  the  target 
record  has  set-significant  Items  as  yet  unassigned,  then  a selection 
criterion  that  will  always  be  satisfied  should  be  given.  For  example, 
line  11  of  Figure  4-4  might  be  replaced  by 

SEX  SELECT  IF  NE  'KING  OF  FRANCE' 

(Selection  criteria  are  discussed  In  detail  In  Section  4.1.7).  This 
difficulty  will  be  corrected  In  subsequent  releases  of  the  Translator. 


i 

4.1.7  Selection  Criteria 


Item  comparisons  are  specified  bv  Item  statements  of  the  form: 

source-item-name  SELECT  IF  op  f Woaf^  ) 

\l1tera1j 

op  Is  one  of  the  comparison  operators  EQ  (equal  to),  NE  (not  equal  to), 
GT  (greater  than),  GE  (greater  than  or  equal  to),  LE  (less  than  or  equal  to) 
i).  As  before,  literals  must  be  enclosed  In  single  quotes. 


or  LT  (less  than. 

Examples  of  this  type  of  statement  are  lines  14  and  23  of  Figure  4-3 
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The  Restructurer  builds  a target  record  occurrence  from  an  occurrence 
of  a tree  only  If  all  of  the  selection  criteria  for  all  the  nodes  on  the 
tree  are  satisfied.  Thus,  In  our  example,  DAUGHTER  records  will  be  built 
only  from  IDS  records  whose  SEX  Item  Is  equal  to  FEMALE,  and  SON  records 
will  be  built  only  from  IDS  records  whose  SEX  Item  contains  the  character 
string  MALE  followed  by  two  blanks.  No  target  records  will  be  built  from 
KIDS  records  with  SEX  Items  equal  to  'GIRL1,  'BOY',  'MALE**' , 'F 
•M  etc.  If  such  records  exist  In  the  source  database,  the  Infor- 

mation they  represent  will  be  lost  In  the  target  database.  Thus,  It  1$ 
essential  to  verify  that  every  desired  target  record  occurrence  exists 
In  an  occurrence  of  a tree  In  the  source  RIF  that  satisfies  all  of  the 
selection  criteria  specified  for  that  tree. 


4.1.8  Item  Assignments  and  Comparisons  Together 

Sometimes  a restructuring  transformation  will  require  that  a selection 
criterion  be  applied  to  a source  Item  value,  and  If  the  comparison  succeeds 
the  Item  Is  assigned  to  a target  Item.  In  that  case,  both  the  selection 
criterion  and  the  Item  correspondence  may  be  specified  In  an  Item  state- 
ment of  the  form 


Integers 

source- Item-name  SELECT  IF  op{  float  > 

l literal J 

ASSIGN  TO  target-item  name 

This  form  of  the  Item  statement  makes  It  possible  to  describe  completely 
a source  Item's  role  In  a target  record  In  a single  statement.  For  example 
If  the  IDS  record  type  of  Figure  4-2a  were  restricted  to  children  age 
twelve  and  under,  then  lines  19  and  26  of  Figure  4-4  would  be  replaced  by: 

A6E  SELECT  IF  LE  12  ASSIGN  TO  AGE. 

This  Is  equivalent  to,  but  slightly  more  economical  than, 

AGE  SELECT  IF  LE  12 
AGE  ASSIGN  TO  AGE 


4.1.9  Additional  SOURCE  RECORD  Features 

The  basic  form  of  the  SOURCE  RECORO  statement  Is  adequate  for  trees 
In  which  no  source  record  type  appears  more  than  once,  as  In  the  previous 
two  TDL  examples.  However,  It  Is  sometimes  necessary  and/or  desirable 
to  use  more  complicated  trees  on  which  one  or  more  source  record  types 
appear  at  least  twice.  Figures  4-6  through  4-13  Illustrate  some  of  these 
more  complex  restructuring  transformations.  Figure  4-6  presents  a slightly 
enlarged  version  of  the  "employment"  database  of  Figure  2-9,  and  Figure  4-7 
shows  an  enlarged  version  of  the  semantically  valid  portion  of  Figure  2-10. 
Figure  4-8  contains  additional  trees,  which,  along  with  the  trees  of 
Figure  2-16,  specify  the  representation  of  the  Figure  4-7  target  database 
In  the  source  database  of  Figure  4-6.  Figure  4-9  Is  a TDL  description  of 
a restructuring  transformation  which  takes  the  source  schema  of  Figure 
4-6  to  the  target  schema  of  Figure  4-7.  Figure  4-10  shows  a small 
"ancestry"  database,  and  Figure  4-11,  a restructured  version  of  It. 

Figure  4-12  gives  trees  to  describe  the  restructuring  transformation,  and 
Figure  4-13,  the  corresponding  TDL  description.  These  examples  are  very 


Figure  4-6 

Source  "Employment"  Database 


Item  Correspondences 
Source  Target 


Comparisons 


Target  Record 


OCCUPATION 


ALL-PEOPLE 


HAS- 

OCCUPATION 


SYSTEM 


FATCAT- 

SIBLINGS 


ALL-PEOPLE 


PEOPLE  (PERSON) 


SS«  ♦ SS#<BI6KID> 


CHILD-OF 


PARENT-OF 


£ (PARENT) 


PARENT-LINK 

(PAR-SIB) 


CHILD-OF 


ss#  - ss# 

NAME  ♦ NAME 
NETWORTH  - NETWORTH 
WEIGHT  - WEIGHT 


NAME  f NAME  OF  PERSON 
NETWORTH  a 250000 
WEIGHT  ^ 250 


Comparisons 


Item  Correspondences 
Source  Target 


Target  Record 


SYSTEM 


PEOPLE 


ALL-PEOPLE 


ss#  ss# 

NAME  -*■  NAME 
NET-WORTH  - NET-WORTH 
WEIGHT  - WEIGHT 


WORKS 

FOR 


HAS- 

OCCUPATION 


NAME  OF  OCCUPATION  - NAME<OCC> 


OCCUPATION 


EMPLOYS 


CONTROLS 


CONGLOMERATES 


NAME  - NAME<BOSS 


Figure  4-8  (cont'd) 
Another  Tree 


4-15 


/*  EMPLOYMENT  DATABASE  TDL  */ 

MACRO  SR  LITERALLY  'SOURCE  RECORD' 

MACRO  AV  LITERALLY  'ACCESS  VIA' 

MACRO  AT  LITERALLY  'ASSIGN  TO' 

TARGET  RECORD  CONGLOMERATES 
TOLAP  C0N6L0M 

SR  CONGLOMERATES  AV  ALL-CONG 
ACTUAL  DATA  IN  ORDER 
OTHER  DATA  BY  NAME 
TARGET  RECORD  COMPANIES 
TDLAP  COMP 

SR  CONGLOMERATES  AV  ALL-CONG 
NAME  AT  NAME<CONTROLS> 

SR  COMPANIES  AV  CONTROLS 
ACTUAL  DATA  IN  ORDER 
FOUNDER  SELECT  IF  NE  'DONALD  DUCK' 
TARGET  RECORO  BUILDINGS 
TOLAP  BUILD 

SR  CONGLOMERATES  AV  ALL-CONG 
SR  COMPANIES  AV  CONTROLS 
NAME  AT  NAME<OWNS> 

SR  BUILDINGS  AV  OWNS 
ACTUAL  DATA  IN  OROER 
OTHER  DATA  BY  NAME 
TARGET  RECORD  EMP-LINK 
TDLAP  EMP 

SR  CONGLOMERATES  AV  ALL-CON6 


Figure  4-9 
TDL  Example 
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28.  SR  COMPANIES  AV  CONTROLS 

29.  NAME  AT  NAME<EMPlOYS> 

30.  SR  EMP-LINK  AV  EMPLOYS 

31 . SR  PEOPLE  AV  WORKS-FOR 

32.  SS#  AT  SS#<WORKS-FOR> 

33.  TARGET  RECORD  PARENTS 

34.  TDLAP  PARENT-PATH 

35.  SR  PEOPLE  ID-KID  AV  ALL-PEOPLE 

36.  SS#  AT  SS#<PARENTS> 

37  SR  PARENT-LINK  AV  CHILD-OF 

38.  SR  PEOPLE  ID-PARENT  AV  PARENT-OF 

39.  SS#  AT  SS# 

40.  NAME  AT  NAME 
41  TARGET  RECORD  OCCUPATION 

42.  TDLAP  OCCUPATH 

43.  SR  PEOPLE  AV  ALL-PEOPLE 

44.  SR  OCCUPATION  AV  HAS-0CCUP7TI0N 

45.  NAME  AT  NAME 

46.  TARGET  RECORD  FATCAT- SIBLINGS 

47.  TDLAP  FATCAT 

48.  SR  PEOPLE  ID-PERSON  AV  ALL-PEOPLE 

49.  SS#  AT  SS#<BIG  KID> 

50.  SR  PARENT-LINK  ID-PER-PAR  AV  CHILD-OF 

51.  SR  PEOPLE  ID-PARENT  AV  PARENT-OF 

52  SR  PARENT-LINK  ID-PAR-SIB  AV  PARENT-OF  FROM  ID-PARENT 

53.  SR  PEOPLE  ID-SIB  AV  CHILD-OF  FROM  ID-PAR-SIB 

54.  SS#  AT  SS# 

55.  NAME  SELECT  IF  NE  NAME  FROM  PEOPLE  ID-PERSON  AT  NAME 

56.  NET-WORTH  SELECT  IF  GE  250000  AT  NET-WORTH 

57.  WEIGHT  SELECT  IFGE  250  AT  WEIGHT 
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Flgur®  4-9  (cont'd) 


58.  TARGET  RECORD  PEOPLE 

59.  TDLAP  PEEP 

60.  SR  PEOPLE  AV  ALL-PEOPLE 

61 . ACTUAL  DATA  IN  ORDER 

62.  WEIGHT  SELECT  IF  GE  -4000 

63.  SR  OCCUPATION  AV  HAS-OCCUPATION 

64.  NAME  AT  NAME<OCC> 

65.  SR  EMP-LINK  AV  WORKS-FOR 

66.  SR  COMPANIES  AV  EMPLOYS 

67.  SR  CONGLOMERATES  AV  CONTROLS 

68.  NAME  AT  NAME<BOSS> 

69.  /*  THE  END  */ 

70.  EOF 


Figure  4-9  (cont'd) 
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Figure  4-10 
Ancestry"  Database 
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Figure  4-11 

Restructured  "Ancestry"  Database 
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Figure  4-12 
Fanlly"  Trees 
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Figure  4-12  (cont'd) 


1.  /*  TDL  FOR  FAMILY  TREE  TRIMMING  */ 

2.  MACRO  TREC  LITERALLY  'TARGET  RECORD' 

3.  MACRO  SREC  LITERALLY  'SOURCE  RECORD' 

4.  MACRO  AV  LITERALLY  'ACCESS  VIA’ 

5.  MACRO  IS  LITERALLY  'ASSIGN  TO* 

6.  MACRO  O/M  LITERALLY  ' OWNER/MEMBER' 

7.  MACRO  M/O  LITERALLY  ' MEMBER/OWNER ' 

8.  TREC  PEOPLE 

9.  TDLAP  THE-PEOPLE 

10.  SREC  PEOPLE  AV  CALC-PEOPLE 

11.  NAME  IS  NAME 

12.  AGE  IS  AGE 

13.  NATIONALITY  IS  NATIONALITY 

14.  FATHER-NAME  IS  ASSIGN  TO  FATHER  ASSIGN  TO  NAME<FATHER> 

15.  SREC  MOTHERS  AV  CHILD-OF 

16-  NAME  IS  MOTHER,  IS  NAME<MOTHER> 

17.  TREC  FATHERS 

18.  TDLAP  DADDY 

19.  SREC  PEOPLE  ID-PERSON  AV  CALC-PEOPLE 

20.  SREC  PEOPLE  ID-DAD  AV  FATHER-OF  M/0 

21.  NAME  IS  NAME 

22.  NATIONALITY  IS  NATIONALITY 

23.  AGE  IS  AGE 

24.  TREC  MOTHERS 

25.  TDLAP  MAMA 

26.  SREC  PEOPLE  ID-MOM  AV  CALC-PEOPLE 

27.  AGE  IS  AGE 

28.  NATIONALITY  IS  NATIONALITY 

29.  SREC  PEOPLE  ID-KID  AV  CALC-PEOPLE 

30.  SREC  MOTHERS  AV  CHILD-OF  FROM  ID-KID 

31.  NAME  SELECT  IF  EQ  NAME  FROM  PEOPLE  ID-MOM  IS  NAME 

32.  NUMBER-OF-KIDS  IS  NUMBER-OF-KIDS 


Figure  4-13 
TDL  for  Ancestry 
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33.  TREC  PATERNAL-GRANDFATHERS 

34.  TDLAP  GRAHPS 

35.  SREC  PEOPLE  IO-PERSON  AV  CALC-PEOPLE 

36.  NAME  IS  NAHE<GRANDPA> 

37.  SREC  PEOPLE  ID-DAD  AV  FATHER-OF  M/0 

38.  SREC  PEOPLE  ID-GRAIDDAD  AV  FATHER-OF  FROM  ID-DAD  M/O 

39.  NAME  IS  NAME 

40.  AGE  IS  AGE 

41 . /*  DONE  WITH  ANCESTRY  TDL  */ 

42.  EOF 
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contrived,  of  course,  and  they  are  not  Intended  as  examples  of  "real  life" 
restructuring  transformations.  However,  they  are  useful  In  Illustrating 
a variety  of  TOL  features. 

The  source  database  of  Figure  4-6  represents  the  Information  contained 
In  the  database  of  Figure  2-9,  and  In  addition,  contains  a WEIGHT  Item  In 
the  PEOPLE  record,  another  record  type,  OCCUPATION,  and  a set,  HAS-OCCUPATION. 
An  Instance  of  HAS-OCCUPATION  consists  of  an  Instance  of  PEOPLE  as  owner, 
and  one  Instance  of  OCCUPATION  as  member.  The  NAME  Item  in  the  OCCUPATION 
record  gives  the  person's  current  occupation.  The  fact  that  an  Instance 
of  HAS-OCCUPATION  can  have  no  more  than  one  member  Instance  Is  reflected 
In  the  choice  of  primary  loey  for  OCCUPATION. 

The  target  database  of  Figure  4-7  is  an  enlarged  version  of  the 
target  database  of  Figure  2-10.  In  addition  to  the  restructuring  described 
by  Figure  2-16,  this  example  Inverts  the  relationship  between  PEOPLE  and 
OCCUPATIONS,  and  contains  a new  record  type,  FATCAT-SIBLINGS,  and  a new 
set,  BI6-KID.  An  Instance  of  BIG-KID  consists  of  a PEOPLE  record  as 
owner,  and  as  members,  one  FATCAT-SIBLINGS  record  for  each  of  the  person's 
siblings  who  Is  worth  at  least  $250,000  and  weighs  at  least  250  pounds. 

The  basic  TDL  statements  are  adequate  to  describe  the  source  database 
Implementations  of  the  target  records  CONGLOMERATES,  COMPANIES,  BUILDINGS, 
EMP-LINK,  OCCUPATION,  and  PEOPLE.  However,  the  source  record  type  PEOPLE 
appears  twice  on  the  tree  used  to  represent  the  PARENTS  records.  Each 
appearance  has  been  given  an  Identifier  which  distinguishes  It  from  the 
others.  The  rule  Is:  whenever  a source  record  type  appears  In  more  than 
one  SOURCE  RECORD  statement  In  a TDLAP  statement,  then  each  appearance 
must  be  given  an  Identifier.  Identifiers  must  be  unique  across  all  SOURCE 
RECORD  statements  In  the  TDLAP,  and  must  be  one  to  twelve  characters  In 
length.  They  are  specified  by: 

ID  * Identifier 

Inmedlately  following  source  record  type  names  In  SOURCE  RECORD  statements. 
Examples  are  lines  35,  38,  48,50,  51,  52,  and  53  of  Fioure  4-9.  This  construc- 
tion also  occurs  frequently  In  the  TDL  description  of  Figure  4-13. 

The  primary  purpose  of  these  identifiers  Is  to  resolve  ambiguities  In 
tree  descriptions  caused  by  multiple  appearances  of  a source  record  type. 

Since  RIF  sets  have  one  member  and  one  owner  type,  specification  of  the 
source  record  type  of  node  and  the  set  which  connects  it  to  Its  parent 
node  Is  enough  to  specify  the  source  record  type  of  the  parent  node.  For 
example,  line  7 of  Figure  4-9  Indicates  that  CONGLOMERATES'  parent  node 
record  type  Is  SYSTEM,  line  14  Indicates  that  COMPANIES'  parent  node  Is 
a CONGLOMERATES  record,  and  line  22  Indicates  COMPANIES  as  the  parent  node 
type  for  BUILDINGS.  If  each  source  record  type  appears  at  most  once  on  a 
TDLAP,  then  each  SOURCE  RECORD  statement  uniquely  determines  a parent  node, 
as  In  the  TDLAPS  CONGLOM,  COMP,  BUILD,  etc  of  Figure  4-9.  However,  when 
a source  record  type  appears  twice  or  more  on  a TDLAP,  and  It  Is  to  be  the 
parent  of  some  other  node  on  the  tree,  then  Its  Identifier  must  be  given 
In  the  child  node's  SOURCE  RECORD  statement  in  order  to  determine  completely 
the  parent  node.  This  Is  the  case  In  the  TDLAP  FATCAT  of  Figure  4-9,  which 
describes  FATCAT-SIBLINGS  records.  In  lines  52  and  53, 

FROM  ID  - Identifier 

Imnedlately  following  the  source-set-name  In  the  SOURCE  RECORD  statement 
specifies  the  correct  parent  node.  This  TDL  feature  Is  also  used  In 
Figure  4-13. 
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Still  nore  Information,  the  direction  of  access.  Is  required  In  a 
SOURCE  RECORD  statement  when  a source  set's  owner  and  member  types  are  the 
same.  This  may  occur  when  the  source  IDS  database  contains  a match-key 
set  or  phantom  pointer  relation  with  the  same  owner  and  member  types.  In 
the  example  of  Figure  4-10,  FATHER-OF  was  a match-key  set  In  the  IDS  source 
database,  with  owner  match-key  field  NAME  and  member  match-key  field  FATHER- 
NAME.  (Notice  that  FATHER-NAME  and  NAME<FATHER>  In  the  PEOPLE  record  of 
Figure  4-10  will  always  contain  the  same  data.  However,  FATHER-NAME  Is  an 
actual  data  Item  accessible  to  the  user,  whereas  NAME-FATHER>  Is  a set- 
significant  Item  available  only  to  the  Restructured.  In  line  20  of 
Figure  4-13,  "M/0",  which  Is  a macro  for  "MEMBER/OWNER"  Is  used  to 
Indicate  that  an  Instance  of  the  parent  node  (POISON)  Is  to  be  a member  of 
the  FATHER-OF  set  owned  by  the  child  node  (DAD).  Thus,  there  can  be  at 
most  one  Instance  of  the  TDLAP  "DADDY"  containing  a given  instance  of 
PEOPLE  as  the  PERSON.  On  the  other  hand.  If  M/0  were  replaced  by  0/M 
(owner/member),  then  an  Instance  of  DADOY  would  contain  a PEOPLE  record 
Instance  as  the  PERSON  and  a member  of  Its  FATHER-OF  set  as  the  DAD.  Thus, 
there  would  be  perhaps  many  Instances  of  DADDY  for  a given  PERSON,  and 
this  would  lead  to  a wealth  of  invalid  FATHERS  records. 

In  line  36  of  Figure  4-13,  both  a FROM  specification  and  an  M/0  speci- 
fication are  required.  The  complete  form  of  the  SOURCE  RECORD  statement  Is 
as  follows: 


SOURCE  RECORD  source-record-name  [IDMdentlfler] 

ACCESS  VIA  source-set-name  frnuNFo/iiruncDv'l 

be  ^rr]  [(S=)J 


4.1.10  Item  vs.  Item  Comparisons 


Some  restructuring  transformations  require  comparisons  of  items  on  a 
tree  with  other  Items  on  the  tree  rather  than  constant  values.  This  Is 
done  In  the  TDLAP  FATCAT  of  FIGURE  4-9,  where  a check  Is  made  (at  line  55) 
to  see  that  a person  Is  not  recorded  as  her  or  Ms  own  sibling,  and  In  the 
TDLAP  MAMA  of  Figure  4-13,  In  which  line  31  1$  used  to  guarantee  that 
target  MOTHERS  record  occurrences  are  built  only  from  source  PEOPLE  and 
MOTHERS  records  describing  the  same  person. 

The  selection  criterion  syntax  for  Item-vs-ltem  comparisons  Is 

source-ltem-namei  SELECT  IF  op  source-item-name2 

[FROM  source-record-name  [ID*1dent1f1er]] 

The  FROM  specification  must  be  used  If  source- 1tem-name2  does  not  belong 
to  the  same  node  as  source- 1 tern-name i.  The  source- record-name  given  must 
have  previously  appeared  on  the  TDLAP.  An  Identifier  must  be  given  If  It 
has  appeared  more  than  once. 


4.1.11  Multiple  Assignments  and  Comparisons 

In  some  cases,  a given  source  Item  mpy  represent  more  than  one  target 
Item,  as  In  the  THE-PEOPLE  TDLAP  of  Figure  4-13.  As  shown  In  lines  14 
and  16  of  Figure  4-13,  a list  of  target  Item  assignments  may 
be  used  In  place  of  a single  target-item-name  In  an  Item  assignment  statement. 
The  only  limit  on  the  length  of  such  a list  Is  the  number  of  Items  In 
the  target  record. 


Similarly,  a source  Item  may  be  required  to  satisfy  more  than  one 
selection  criterion.  For  example.  If  FATCAT-SIBLINfiS  mere  restricted  to 
heavy  people  worth  at  least  $250,000  but  no  more  than  $1,000,000,  then 
line  56  of  Figure  4-9  would  be  replaced  by: 

NET-WORTH  SELECT  IF  GE  250000  SELECT  IF  LE  1000000 
AT  NET-WORTH 

The  almost-complete  syntax  of  an  Item  statement  Is: 
source- Item-name 


SELECT  IF  op 


Integer 
float 
literal 

source-1  tern-name  [FROM  source-record-name 

[I  identifier]] 


o 


[ASSIGN  TO  target-1 tern-name ]£ 

Two  more  constructs  are  available  In  Item  statements.  They  specify 
user-implemented  selection  criteria  and  conversions  and  are  described 
In  Section  4.2.3. 


4.2  Advanced  TOL  Features 

Sections  4.2.1  and  4.2.2  describe  TOL  features  that  may  save  the 
experienced  TOL  writer  time  and  effort.  However,  they  require  a thorough 
understanding  of  the  semantics  of  the  source  and  target  databases,  and 
should  be  used  with  caution  by  TOL  beginners.  Section  4.2.3  gives  specifi- 
cations for  user-written  qualification  and  conversion  routines.  Such 
routines  are  used  to  perform  conversion  and  apply  selection  criteria  that 
are  not  handled  directly  by  the  Restucturer. 


4.2.1  ACCEPT/REJECT  IF  NULL 

In  some  restructuring  transformations.  It  Is  daslrable  to  be  able  to 
create  target  record  occurrences  even  when  a collate  Instance  of  a 
TDLAP  Is  not  found.  For  example,  consider  Figure  4-14,  which  shows  a very 
simple  source  database,  target  database,  tree,  and  TOL  description. 
Information  about  people  whose  occupation  Is  not  recorded  In  the  database 
will  be  lost,  since  for  them,  no  complete  Instance  of  PEOPLE-BUILD  exists 
In  the  source  data.  However,  It  may  be  desirable  to  create  target  PEOPLE 
record  occurrences  for  such  people,  and  assign  their  OCCUPATION  Items  the 
value  'UNKNOWN'.  This  can  be  accomplished  by  the  use  of  ACCEPT  IF  NULL. 

The  statement  Immediately  following  a SOURCE  RECORD  statement  header  may 

h*  {J™I}  IF  NULL.  REJECT  IF  NULL  Is  the  default,  that  Is,  It  Is 
assuMKTTf  no  such  statement  Is  given.  REJECT  requires  that  an  Instance 
of  the  source  record  be  found  In  order  to  construct  a target  record  Instance. 


CALC-OCCUPATION 


CALC-PEOPLE 


C-PEOPLE 


OCCUPATION 


OCCUPATION-OF 


SYSTEM 


CALC-PEOPLE 


PEOPLE 


CUPATION-OF 


OCCUPATION 


NAME  EDUCATION  OCCUPATION 


NAME  EDUCATION 


b.  Target  Database 


a.  Source  Database 


NAME  - NAME 
EDUCATION  - EDUCATION 


NAME  - OCCUPATION 


c.  Tree  Representing  Target  PEOPLE 


Figure  4-14 
Simple  Example 
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1 . TARGET  RECORD  PEOPLE 

2.  TDLAP  PEOPLE-BUILD 

3.  SOURCE  RECORO  PEOPLE  ACCESS  VIA  CALC-PEOPLE 

4.  NAME  ASSIGN  TO  NAME 

5.  EDUCATION  ASSIGN  TO  NAME 

6.  SOURCE  RECORD  OCCUPATION  ACCESS  VIA  OCCUPATION-OF 

7.  NAME  ASSIGN  TO  OCCUPATION 

8.  EOF 
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d.  TDL  Description 


0 

0 

0 

Q 

D 

0 

Figure  4-14  (cont'd) 
Simple  Example 
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ACCEPT  directs  the  Restructurer  to  construct  a target  record  Instance  even 
If  an  Instance  of  the  source  record  Is  not  found  (l.e.,  the  source  record 
Is  null).  The  target  Items  that  would  have  been  assigned  values  from  the 
source  record  are  assigned  "null  values"  Instead.  Every  Item  assignment 
statement  of  an  ACCEPT  IF  NULL  source  record  must  specify  a null  value. 

The  format  Is: 


source-1  tern-name  ASSIGN  TO 

[target- Item-name  NULL  VALUE 


Integer 
(float  }], 
literal  1 


Figure  4-15  contains  a rewritten  version  of  the  TDL  description  of  Figure 
4-14  using  this  feature. 

Two  Important  restrictions  are  Imposed  on  ACCEPT  IF  NULL.  First, 
any  selection  criterion  which  references  an  Item  belonging  to  a source 
record  will  fall  if  the  source  record  Is  null,  whether  or  not  It  Is  an 
ACCEPT  IF  NULL  record.  This  applies  to  selection  criteria  specified  for 
the  source  record,  and  for  inter-record  comparisons  In  which  Its  1tem(s) 
are  compared  to  Items  from  other  records.  Secondly,  and  obviously,  all 
children  of  an  ACCEPT  IF  NULL  node  on  a tree  must  also  be  ACCEPT  IF  NULL 
nodes . 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 


TARGET  RECORD  PEOPLE 
TDLAP  PEOPLE  BUILD 

SOURCE  RECORD  PEOPLE  ACCESS  VIA  CALC-PEOPLE 
NAME  ASSIGN  TO  NAME 
EDUCATION  ASSIGN  TO  EDUCATION 
SOURCE  RECORD  OCCUPATION  ACCESS  VIA  OCCUPATION-OF 
ACCEPT  IF  NULL 
NAME  ASSIGN  TO  OCCUPATION 

NULL  VALUE  * 'UNKNOWN' 


9.  EOF 


Figure  4-15 

Rewritten  Simple  Example 


As  another  example,  suppose  that  In  the  ancestry  restructuring  of 
Figures  4-10  through  4-13,  we  wish  to  create  PEOPLE  record  occurrences 
even  If  the  mother  Is  unknown.  Then  lines  15-16  of  Figure  4-13  might  be 
replaced  by: 


15 
15. 

16 


SREC  MOTHERS  AV  CHILO-OF 
ACCEPT  IF  NULL 

NAME  IS  MOTHER  NULL  VALUE  « 'NOT-KNOWN' 
IS  NAME<MOTHER>  NULL  VALUE  * ' 
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MOTHER  and  NAME<MOTHER>  are  given  different  null  values,  since  MOTHER 
will  exist  In  the  IDS  target  database  where  it  will  Indicate  that  the 
mother's  name  Is  unknown  whereas  NAME<MOTHER>  is  a set-significant  Item 
which  must  contain  a value  that  will  not  match  any  MOTHER  record's  NAME. 


4.2.2  Use  of  Set-significant  Source  Items 


Set-significant  Items  In  a source  record  may  be  used  In  selection 
criteria  and  assignments  In  the  same  wey  that  actual  data  Items  are  used, 
subject  to  one  restriction:  a TDLAP  which  uses  set-significant  Items 
this  way  may  not  use  ACCEPT  IF  NULL. 

For  example , Figure  4-16  shows  a rewritten  version  of  the  TDLAP  EMP 
of  Figure  4-9  using  source  set-significant  Items.  When  source  set-slgnlfl 
cant  Items  are  used.  It  should  be  remembered  that  they  are  present  only 
If  the  source  record  Instance  Is  a member  of  the  set  to  which  they  are 
significant.  If  not,  a target  record  Instance  Is  not  created.  Thus,  In 
the  example  of  Figure  4-16,  just  as  In  4-9,  target""EfiP-LINK  records  are 
constructed  only  from  source  EMP-LINK  records  which  belong  to  both  the 
WORKS- FOR  and  EMPLOYS  sets. 


sets. 


TARGET  RECORD  EMP-LINK 
TDLAP  EMP 

SR  CONGLOMERATES  AV  ALL-CONG 
SR  COMPANIES  AV  CONTROLS 
SR  EMP-LINK  AV  EMPLOYS 

NAME<EMPLOYS>  AT  NAME<EMPLOYS> 
SS#<W0RKS-F0R>  AT  $S#<WORKS-FOR> 

Figure  4-16 

Source  Set-significant  items  in  Action 


Three  statements  permit  name-by-name  assignment  of  blocks  of 
Items.  They  are: 

SET-SIGNIFICANT  DATA  BY  NAME 
OTHER  DATA  BY  NAME 
ALL  DATA  BY  NAME 

SET-SIGNIFICANT  DATA  BY  NAME  Is  used  when  all  of  the  target  record's 
set-significant  Items  that  have  not  been  explicitly  assigned  are  to 
receive  the  values  of  set-significant  Items  of  the  same  name  in  the  source 
record.  For  example,  lines  6 and  7 of  Figure  4-16  could  be  replaced 
by  the  single  line: 

6.  SET-SIGNIFICANT  DATA  BY  NAME 

OTHER  DATA  BY  HNHE  has  the  same  effbct,  and  In  addition,  causes  all  of  the 
as  yet  unassigned  actual  data  Items  In  the  target  record  to  be  assigned 
the  values  of  Items  of  the  same  name  In  the  source  record.  For  example, 
lines  39  and  40  of  Figure  4-9  could  be  replaced  by: 

39.  OTHER  OATA  BY  NAME 

Errors  will  result  If  either  of  these  statements  Is  used  and  appropriate 
namesakes  do  not  exist  In  the  source  record. 

Finally,  ALL  DATA  BY  NAME  causes  the  entire  target  record  to  be 
assigned  from  Items  of  the  same  name  In  the  source  record.  It  must  be 
the  only  Item  assignment  statement  on  a TDLAP.  For  example,  lines  22-24 
of  example  4-9  could  be  replaced  by: 

21.  SR  BUILDINGS  AV  OWNS 

22.  ALL  DATA  BY  NAME 
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The  same  block  of  statements  could  also  be  rewritten  as: 

22.  SR  BUILDINGS  AV  OWNS 

23.  ACTUAL  DATA  IN  ORDER 

24.  SET-SIGNIFICANT  DATA  BY  NAME 

In  fact,  the  latter  form  will  actually  lead  to  a more  efficient  Restructurer 
run,  since  IN  ORDER  assignment  executes  more  quickly  than  BY  NAM-  assignment. 
As  a rule,  ACTUAL  DATA  IN  ORDER  should  be  used  whenever  possible.  It 
often  results  in  significant  savings  at  Restructurer  execution  time. 


4.2.3  User-Supplied  Qualification  and  Conversion  Routines 

If  It  Is  necessary  to  perform  more  complicated  item  qualifications  than 
those  using  only  simple  comparison  operators  (LT,  GT,  etc.),  then  a 
separate  subroutine  must  be  written  to  perform  this  qualification.  Likewise, 
If  an  Item  Is  to  be  converted  explicitly  (l.e.,  not  as  described  In  Section 
4.1.6),  a subroutine  must  be  written. 

User- Implemented  selection  criteria  are  specified  In  TDL  Item  state- 
ments as  follows: 

source-item-name  [WHEN  QUALIFIED  BY  11nk-name[(VALUE  STATEMENT  )]]Jj 
where  VALUE  STATEMENT  Is  of  the  form 


f Integer 
) float 
\ literal 

v.  source- item-name  [FROM  source-record-name  [ID*identifier]] 

Link-namejnust  be  a six-character  alphanumeric  name  and  must  begin  with  a 
letter.  This  name  will  be  used  by  the  Restructurer  to  reference  the  actual 
user-supplied  subroutine.  If  more  than  one  user-supplied  subroutine  Is  de- 
sired for  one  source  Item,  the  WHEN  QUALIFIED  BY  clause  must  be  repeated. 

A target  record  Instance  will  be  created  using  a specified  source  item 
value  only  If  all  the  user-supplied  subroutines  indicate  that  ft  passes 
qualification. Also,  note  that  SELECT  IF  clauses  may  precede  the  WHEN 
QUALIFIED  BY  clauses.  In  that  case,  a target  record  Instance  Is  created 
only  when  a)  all  of  the  comparisons  In  the  SELECT  IF  clauses  are  true  and 
b)  all  of  the  user-supplied  subroutines  specified  in  the  WHEN  QUALIFIET5TY 
clauses  Indicate  that  the  Item  passes  qualification.  See  Section  4.3  for 
the  complete  item  statement  syntax. 

Some  user- Implemented  selection  criteria  will  need  only  the  source 
Item  value  as  Input;  others  may  compare  It  to  a constant  value  or  the 
value  of  same  other  Item  on  the  TDLAP.  In  the  latter  case,  the  comparison 
value  Is  specified  In  the  VALUE  STATEMENT.  The  FROM  specification  must  be 
given  If  the  comparison  value  Is  an  Item  that  belongs  to  a TDLAP  node 
different  from  the  one  In  which  the  Item  statement  appears,  and  the  Identifier 
must  be  given  If  the  node  has  one. 

For  example.  In  the  FATCAT-SIBLINGS  TDLAP  of  Figure  4-9,  selection  of 
FATCATS  might  be  more  complex  than  as  shown,  with  lines  56  and  57  rewritten  as: 

56.  NET-WORTH  WHEN  QUALIFIED  BY  HOWRCH(NAME)  ASSIGN  TO  NET-WORTH 

57.  WEIGHT  WHEN  QUALIFIED  BY  HOWFAT  ASSICN  TO  WEIGHT 


% • 


imHim 
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It  may  be  that  WEIGHTS  can  be  positive  or  negative;  a positive  weight  Is  In 
pounds,  and  a negative  one  In  kilograms.  The  subroutine  referred  to  by  HOWFAT 
would  Indicate  that  a positive  weight  satisfies  the  fatness  criterion  If  It  Is 
at  least  250,  and  a negative  weight  passes  If  It  Is  less  than  or  equal  to 
-113.6.  The  subroutine  referred  to  by  HOWRCH  could  consult  a table  Indicating 
the  percentage  of  each  person's  net  worth  that  Is  In  negotiable  form.  Then 
a person  might  qualify  as  a FATCAT  only  If  his  negotiable  net  worth  exceeds 
$100,000. 

As  another  example.  In  the  restructuring  of  Figure  4-13,  It  may  be  that 
NAME  Items  In  MOTHERS  records  contain  prefixes — "OR.",  "MRS.",  or  “MS."  for 
example — but  NAMES  In  PEOPLE  records  do  not.  Then  line  31  of  Figure  4-13 
would  be  replaced  by: 

31.  NAME  WHEN  QUALIFIED  BY  NAMEMP(NAME  FROM  PEOPLE  ID-MOM) 

ASSIGN  TO  NAME, 

where  NAMEMP  refers  to  a routine  which  strips  prefixes  from  names  before 
comparing  them. 

Routines  which  perform  complex  conversions  are  specified  as  follows: 

...ASSIGN  TO  target-1 tern-name  [CONVERT  WITH  11nk-name]J 

For  example,  continuing  with  our  ancestry  example.  It  may  be  desirable  to 
strip  titles  from  MOTHERS'  names  In  the  target  database.  A routine  referred 
to  be  NAMCNV  could  be  written  to  accomplish  this,  and  line  >31  would  read: 

31.  NAME  WHEN  QUALIFIED  BY  NAMCMP  (NAME  FROM  PEOPLE  ID-MOM) 

ASSIGN  TO  NAME  CONVERT  WITH  NAMCNV. 

Both  qualification  and  conversion  subroutines  must  contain  the  following 

COUWN  area  through  which  the  item  values  and  lengths  are  passed. 

C0MM0N/USER/BUF1 ,BUF2,LEN1 .LEN2.IERR 

The  variables  have  the  following  meanings: 

BUF1  An  Integer  array  of  64  words.  This  will  contain  the  value 
of  the  Item  to  be  qualified  or  converted,  with  the  value 
left- Justified. 

LEN1  An  Integer  which  contains  the  length  of  the  Item  field  in 
BUF1.  This  length  is  In  bytes. 

BUF2  An  integer  array  of  64  words.  In  a qualification  subroutine, 
this  will  contain  the  value  of  the  Item  to  be  compared  against 
If  such  a value  was  specified  In  the  TDL.  In  a conversion 
operation,  BUF2  will  contain  the  converted  Item  on  exit  from 
the  subroutine.  This  field  will  be  left- justified. 

LEN2  In  a conversion  operation,  an  integer  which  contains  the 

length  of  the  target  Item  In  the  corresponding  target  record. 
This  length  Is  also  In  bytes. 

I ERR  An  Integer  flag  set  only  by  a qualification  routine  as  a 

flag  for  the  Restructurer: 

0 - Item  accepted 

1 - Item  rejected 

A user-supplied  subroutine  must  be  compiled  Into  an  object  file  before 
the  Restructurer  Is  run.  This  object  file  must  then  be  specified  as  a $LINK  In 
the  control  card  deck  setup  for  the  Restructurer.  This  Is  detailed  In  Section 
8.7.  The  name  given  to  this  LINK,  l.e.,  link-name.  Is  the  name  by  which  the 
subroutine  will  be  referred  to  In  the  TDL. 


If  an  item  Is  to  be  user-qualified,  each  time  the  Restructurer 
module  accesses  the  Item*  It  will  link  In  the  qualification  subroutine 
and  pass  control  to  It.  The  Item  to  be  qualified  wtll  be  In  BUF1  and  a 
second  Item  value  will  be  In  BUF2  If  one  was  specified  In  the  TDL.  The 
qualification  subroutine  will  return  a zero  (0)  In  IERR  If  the  Item  Is  to 
be  accepted,  and  a one  (1)  If  the  Item  Is  to  be  rejected. 

Likewise,  If  an  Item  Is  to  be  user-converted,  each  time  the  Restructurer 
Is  about  to  assign  the  Item  to  a record  In  the  target  RIF,  It  will  link 
In  the  conversion  subroutine  and  pass  control  to  It.  The  Item  to  be 
converted  will  be  In  BUF1,  and  the  subroutine  should  return  the  converted 
value  In  BUF2.  For  example: 

The  following  restructuring  Is  to  be  performed: 


Target  Schema 


SYSTEM 


iYSTEM 


S-DEPART 


S-DEPART 


DEPARTMENT 


DEPARTMENT 


Department  # 


Department  # 


HAS-EMPLOYEES 


HAS-EMPLOYEES 


Job-title 


D#  <HAS> 


An  Admln-Empl  record  Is  to  be  constructed  In  the  target  DB  only  If  the 
employee’s  job  title  is  'Manager'  or  'Secretary'.  The  TDL  required  Is: 

1.  TARGET  RECORD  DEPARTMENT 

2.  TDLAP  DEPART 

3.  SOURCE  RECORD  DEPARTMENT  ACCESS  VIA  S-DEPART 

4.  ACTUAL  DATA  IN  ORDER 

5.  SET  SIGNIFICANT  DATA  BY  NAME 

6.  TARGET  RECORD  ADMIN- EMPL 

7.  TDLAP  ADHIN 

8.  SOURCE  RECORD  DEPARTMENT  ACCESS  VIA  S-DEPART 

9.  * SOURCE  RECORD  EMPLOYEE  ACCESS  VIA  HAS-EMPLOYEES 

10.  JOB-TITLE  WHEN  QUALIFIED  BY  ALINK  ASSIGN  TO  JOB-TITLE 

11.  OTHER  DATA  BY  NAME 

12.  EOF 

The  subroutine  required  by  this  TDL  must  be  written  and  compiled  Into  the 
module  which  has  the  link  name  ALINK  in  the  Restructurer  control  cards. 
The  subroutine  needed  Is: 


SUBROUTINE  USERQ1 

COMMON/USER/BUF1 , BUF2,  LEN1 , LEN2,  I ERR 
INTEGER  BUFI (64),  BUF2(64),  LEN1 , LEN2,  I ERR 
INTEGER  SECY (2),  MNGR(2) 

DATA  SECY/6HSECRET,  6HARY  / 

DATA  MNGR/6HMANAGE,  6HR  / 

IERR*1 

IF  (BUFI (1 ) . EQ. SECY (1 ) .AND. BUFI (2 ) . EQ. SECY (2 ) 

& .OR.BUF(l  ).EQ.MNGR(1 ) .AND. BUFI  (2).EQ.MNGR(2)) 
& IERR-0 
RETURN 
END 


Example:  Restructuring  Is  to  be  performed  where  the  old  inventory  numbers 
are  to  be  suffixed  with  '000'  to  allow  for  more  inventory  numbers  in  the 
new  system. 

Source  Schema  Target  Schema 


SYSTEM 


SYSTEM 


WAREHOUSE 


WAREHOUSE 


Hargiiflu&e  f 


HAS- ITEMS 


INVENTORY 


INVENTORY 


Inventory  # 


W#  <HAS> 


Inventory  # 


The  TDL  required  is: 

1 . TARGET  RECORD  WAREHOUSE 

2.  TDLAP  WAREHOUSE 

3.  SOURCE  RECORD  WAREHOUSE  ACCESS  VIA  S-WARE 

4.  ACTUAL  DATA  IN  ORDER 

5.  SET  SIGNIFICANT  DATA  BY  NAME 

6.  TARGET  RECORD  INVENTORY 

7.  TDLAP  INVENTORY 

8.  SOURCE  RECORD  WAREHOUSE  ACCESS  VIA  S-WARE 

9.  SOURCE  RECORD  INVENTORY  ACCESS  VIA  HAS- ITEMS 

10.  INVENTORY#  ASSIGN  TO  INVENTORY#  CONVERT  WITH  BLINK 

11.  SET  SIGNIFICANT  DATA  BY  NAME 

12.  EOF 


The  user  conversion  subroutine  required  by  the  above  TDL  must  be 
written  and  compiled  Into  the  module  which  has  the  name  BLINK  In  the 
Restructurer  control  cards.  The  subroutine  needed  Is: 

SUBROUTINE  USERC1 

C0NM0N/USER/BUF1 , BUF2,  LENT , LEN2 , I ERR 
INTEGER  BUF1 (64),  BUF2(64),  LEN1 , LEN2,  I ERR 
INTEGER  SUFFIX 
DATA  SUFFIX/ 6H000  / 

CALL  SMOVE*(BUF2,1 ,BUF1 ,1 ,LEN1 ) 

CALL  SHOVE(BUF2,LENl+1, SUFFIX, 1,3) 

RETURN 

END 

♦SHOVE  Is  a routine  that  has  the  following  form: 

CALL  SHOVE  (buf-1,  start-1,  buf-2,  start-2 ,1en) 
buf-1  - address  of  the  variable  to  which  a string  Is  moved 
start-1  - displacement  (In  characters)  within  buf-1  where  the 
"MOVED"  string  will  start 

buf-2  - address  of  the  variable  containing  the  string  to  move 
start-2  - displacement  (In  characters)  within  buf-2  where  the  string 
begins 

len  - # of  characters  to  be  moved 
Example 

buf-1  ABCDEFGH 
buf-2  bbbDEFbb 

To  move  the  string  "DEF"  Into  the  position  Indicated  in  buf-2,  the  following 
SHOVE  call  Is  required: 

CALL  SHOVE  (BUF2,4,BUF1 ,4,3) 

SHOVE  Is  available  within  the  Translator  library. 

Example:  A common  use  of  user-supplied  conversion  routines  might  be  the  pre- 
servation of  alphanumeric  Items  when  a)  the  source  item  length  Is  greater 
than  the  target  Item  length,  and  b)  the  Item  values  are  right  justified. 

Suppose  a target  Item  called  POPULATION  (data  type  character,  1ength6) 
Is  to  be  assigned  from  a source  Item  POPULATION-OF-CITY  (data  type  character 
length  10).  The  desired  result  IS: 

source  Item  target  Item 

POPlOTfON-OF-CITY  POPULATION 

2 7 6 3 0 0 2 7 6 3 0 0 

However,  If  no  conversion  routine  Is  supplied,  the  actual  result  will  be: 


To  avoid  the  unwanted  truncation,  a user-supplied  subroutine  must  be  used 
The  corresponding  TDL  clause  might  read: 

POPULATION-OF-CITY  ASSIGN  TO  POPULATION  CONVERT  WITH  REJUST, 

where  REJUST  refers  to  the  following  subroutine: 

SUBROUTINE  USERC2 

COMMON/US ER/BUF1 ,BUF2,LEN1 .LEN2.IERR 
INTEGER  BUF1 (64) ,BUF2(64) ,LEN1 ,LEN2,IERR 
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INTEGER  START 

START.  « LEN1-LEN2  + 1 

CALL  SM0VE(BUF2,1 ,BUF1 .START, LEN2) 

RETURN 

END 

In  this  case,  START  * 10-6+1-5;  six  characters  will  be  moved  from  BUF1 
to  BUF2,  the  fifth  through  the  tenth,  producing  the  desired  result.  Note 
the  use  of  the  Translator-supplied  routine  SHOVE  as  In  the  previous  example 
The  subroutine  USERC2  must  be  compiled  Into  an  object  file,  which  Is  then 
Inserted  Into  the  Restructurer  R*  file  In  a program  link  called  REJUST. 
Again,  the  reader  Is  referred  to  Section  8.7  for  details. 


A.  TARGET  RECORD  STATEMENT 

TARGET  RECORD  target-record-name 
[TDLAP  STATEMENT]” 

Rules 

”1.  A TDL  description  must  contain  exactly  one  TARGET  RECORD  statement 
for  each  target  database  record  type. 

B.  TDLAP  STATEMENT 

TDLAP  tdlap-name  Integer 

[target-item-name  - (float  } ]JI 

literal  u 

rcruiDTC  nrrnnn  emmieur'l” 


[SOURCE  RECORD  STATEMENT]’ 


1.  Tdlap-name  is  1-12  characters,  unique  over  all  TDLAP  statements 
In  the  TDL  description. 

2.  Each  target-item-name  specifies  a target  item  which  Is  to  be 
assigned  the  specified  value  In  each  target  record  Instance 
created  using  this  access  path. 

SOURCE  RECORD  STATEMENT 

SOURCE  RECORD  source-record-name  [ I D« identifier^] 

ACCESS  VIA  source-set-name  [FROM  ID-ldentifierg] 

OWNER/MEMBER 
.rr-0T  MEMBER/OWNER 

C{RijECT}  IF  ^ 


[ACTUAL  DATA  IN  ORDER] 
[ITEM  STATEMENT]" 


[BLOCK  ASSIGNMENT  STATEMENT] 


If  source-record-name  a-pears  In  any  other  SOURCE  RECORD  statement 
on  the  TDLAP,  the  "ID-"  clause  must  be  used. 

Identifier  Is  1-12  characters  In  length,  and  must  be  unique 


over  all  Identifiers  specified  on  the  TDLAP. 

source- record-name  must  be  the  owner  or  member  record  type  for 
source-set-nmne . 


4.  If  source- record-name  Is  the  owner  record  type  for  source-set-name, 
then  at  least  one  SOURCE  RECORD  statement  containing  the  member 
record  type  for  source-set-name  must  appear  previously  on  the  TDLAP. 
If  source-record-name  Is  the  member  record  type  for  source-set-name, 
and  source-set-name  Is  not  system-owned,  then  at  least  one  SOURCE 
RECORD  statement  containing  the  owner  record  type  for  source-set- 
name  must  appear  previously  on  the  TDLAP. 

5.  If  more  than  one  such  SOURCE  RECORD  statement  has  appeared,  the 
"FROM"  clause  must  be  used,  and  Identifier-  must  be  the  Identifier 
specified  for  the  desired  parent  node.  c 

6.  If  source- record-name  Is  both  the  owner  and  member  record  type  for 
source-set-name,  the,MEMBER/0WNER,opt1on  must  be  used. 

lOWNER/MEMBER' 

7.  REJECT  IF  NULL  Is  assumed  If  the  rACCEPT*opt1on  Is  not  used. 

1 REJECT' 

"ACTUAL  DATA  IN  ORDER"  Rules 

1.  The  actual  data  Items  In  the  source  record  type  must  correspond 
1-for-l  and  In  order  with  the  actual  data  Items  In  the  target 
record  type.  Primary  key  Items  In  the  source  record  must 
correspond  1-for-l  with  primary  key  Items  In  the  target  record. 

No  target  actual  data  Item  name  may  appear  In  an  Item  assignment 
statement  on  the  TDLAP. 

2.  Each  source  actual  data  Item  must  have  the  same  length  and  pad 
character  as  Its  corresponding  target  actual  data  Item. 

3.  ACTUAL  DATA  IN  ORDER,  when  It  Is  used,  must  be  the  first,  and  may 
not  be  the  last.  Item  statement  In  a SOURCE  RECORD  statement. 

D.  ITEM  STATEMENT 

source-1tem>name 

[SELECT  IF  op  VALUE  STATEMENT] J 

[WHEN  QUALIFIED  BY  link-name  [(VALUE  STATEMENT }]]£ 


SIGN  TO 


target- Item  name 

[CONVERT  WITH  routlne-nmne 


[NULL  VALUE 


f Integer 
float 
^literal 


}>J 


Rules 


See  Figure  4-5,  page  4-8  for  Implicit  Item  conversion  rules. 

If  ACCEPT  IF  NULL  Is  used  In  an£  SOURCE  RECORD  statement  on  the 
TDLAP,  source-item-name  may  not  be  the  name  of  a set-significant 
Item. 

A target  record  Instance  Is  created  If  and  only  If  all  comparisons 
specified  on  the  TDLAP  are  satisfied. 


4-37 


a 

0 

0 


0 


D 


o 


4.  Results  of  comparisons  are  unpredictable  If  the  quantities  compared 
are  of  different  lengths  or  data  types. 

5.  NULL  VALUES  must  be  specified  for  all  Item  assignment  statements 
when  ACCEPT  IF  NULL  was  used  In  the  SOURCE  RECORD  statement,  and 
cannot  be  specified  for  Items  belonging  to  REJECT  IF  NULL  source 
records. 

6.  See  Section  4.2.3  for  a detailed  description  of  the  interface  to 
user-supplied  qualification  and  conversion  routines. 

BLOCK  ASSIGNMENT  STATEMENTS: 

SET-SIGNIFICANT  DATA  BY  NAME 

OTHER  DATA  BY  NAME 

ALL  DATA  BY  NAME 

Rules 

1.  SET-SIGNIFICANT  DATA  BY  NAME  Is  used  to  assign  values  to  all  the 
set-significant  Items  In  a target  record  that  have  not  yet  been 
assigned  values.  Each  of  the  target  record's  remaining  set- 
significant  Items  Is  assigned  the  value  of  the  source  record's 
set-significant  Item  of  the  same  name  (which  must  exist). 

2.  OTHER  DATA  BY  NAME  has  the  same  effect  as  SET-SIGNIFICANT  DATA 
BY  NAME,  except  that  It  causes  every  target  Item  not  previously 
assigned  to  be  given  the  value  of  the  source  Item  of  the  same 
name.  This  applies  to  both  set-significant  and  actual  data  Items. 
OTHER  DATA  BY  NAME,  when  used,  must  be  the  last  Item  assignment 
statement  on  the  TDLAP. 

3.  ALL  DATA  BY  NAME  causes  every  target  Item  to  be  assigned  the  value 
of  the  source  Item  of  the  same  name.  When  used.  It  must  be  the 
only  Item  assignment  statement  on  the  TDLAP. 

4.  If  ACCEPT  IF  NULL  Is  used  In  an*  SOURCE  RECORD  statement  on  the 
TDLAP,  BLOCK  ASSIGNMENT  statements  may  not  be  used. 

E.  VALUE  STATEMENT 


Integer 

float 

literal 

source-item-name 

[FROM  source-record-name  [ID«1dent1f1er]] 

Rules 

1 . source-1  tern-name  may  not  be  the  name  of  a set-significant  Item 
If  ACCEPT  IF  NULL  Is  used  with  any  SOURCE  RECORD  statement  on 
the  TDLAP. 

2.  The  "FROM"  option  must  be  used  If  source-item-name  does  not  be- 
long to  the  same  source  record  as  the  Item  to  which  It  will  be 
compared.  Source-record-name  must  have  appeared  previously  In 

a SOURCE  RECORD  statement  on  the  TDLAP,  and  If  It  appears  In  more 
than  one  SOURCE  RECORD  statement,  Its  Identifier  must  be  given. 


i 


5.0  RUNNING  THE  IDS  ANALYZER 

Once  the  user  has  prepared  his/her  source  and  target  database  extended 
IDS  HO  sections  (see  Section  3),  It  Is  necessary  to  convert  these  textual 
database  descriptions  Into  the  tables  used  by  the  Data  Translator.  These 
tables,  the  Stored  Data  Definition  Language  tables  (SDDL),  contain  all  of 
the  Information  necessary  to  describe  the  source  and  target  databases.  This 
process  of  conversion  Is  performed  by  executing  the  IDS  Analyzer  twice,  once 
for  the  source  database(s)  and  similarly,  once  for  the  target  database(s). 

As  described  In  Section  3,  the  general  processing  flow  Is  as  follows: 

1.  Initialize  temporary  IDS  database  for  use  by  IDS  Translator  In 
query  mode. 

2.  Run  IDS  Translator  In  query  mode.  Inputting  the  prepared  extended 
IDS  MD  section  and  outputting  the  IDS  Query  dictionary. 

3.  Read  the  IDS  Query  dictionary  as  Input  to  the  IDS  Analyzer  and 
output  SDOL  tables  and  reports. 

The  above  sequence  Is  done  twice,  once  for  the  source  database(s)  and  again 
for  the  target  database(s). 

Before  executing  the  IDS  Analyzer,  the  following  must  be  performed. 

1.  An  extended  IDS  MD  section  has  been  written.  All  rules  specified 
In  Section  3 of  this  User  Manual  must  have  been  obeyed.  Further- 
more, as  recommended  In  Section  3.2.1  Rule  #1,  the  IDS  MD  section 
prior  to  augmentation  with  level  61  entries  should  be  compiled 

by  the  IDS  Translator  Into  a dummy  COBOL-IDS  program  so  that  all 
IDS  or  COBOL  errors  can  be  removed. 

2.  A permanent  file  (random) must  be  created  to  hold  each  SDDL  table 
database  (one  for  the  source,  one  for  the  target).  A rule  of 
thumb  to  use  In  creating  the  file  Is 

4 11  Inks/01  record 

3.  The  first  card  of  the  extended  IDS  MD  section  must  be  an  IDS 

QUERY  card.  "IDS  QUERY"  must  begin  exactly  In  column  8.  All 
cards  starting  with  "MD"  must  be  removed.  Hence  an  extended  IDS 
MD  section  will  look  like  the  following  prior  to  IDS  Analyzer 
execution.  No  line  within  the  extended  MD  section  may  extend 
beyond  column  72.  Additionally,  If  the  extended  MD  section  Is 
in  a file,  tab  characters  of  V should 


not  be  used  under  any  circumstances 


IDS  QUERY 
01  record  ... 

02-49  plus  level  61  entries 
96  entries 


01  record  ... 

02-49  plus  level  61  entries 
98  entries 


01  record  ... 

02-49  plus  level  61  entries 
08  entries 


Figure  5-1 
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Phase  2 IDS 
Analyzer 


An  R*  file  containing  the  object  version  of  the  second 
phase  of  the  IDS  Analyzer. 


Runtime  parameters  An  ASCII  file  with  the  information  on  which  database 

and  records  are  being  analyzed.  See  Section  5.6  for 
complete  details. 

Scratch  Input  file  A null-linked  file  that  must  be  attached  for  use  by 

the  AOBMS  system. 

SDDL  tables  An  AOBMS  database  containing  the  Data  Translator 

representation  of  the  user  database(s).  One  SDDL  tables 
file  1$  sufficient  for  up  to  five  source  or  target 
database  descriptions.  Source  SDDL  tables  are  used  by 
the  Reader,  TDL  Analyzer  and  Restructurer.  Target 
SDDL  tables  are  used  by  the  TDL  Analyzer,  Restructurer 
and  Mrlter. 

SDOL  DBTF  The  database  tables  file  describing  to  AOBMS  the  format 

and  contents  of  the  SDDL  tables  database.  See  Appendix 

F. 

Internal  Work  A temporary  AOBMS  databas%.sed  to  cawuo^atc  Informa- 

database  tlon  between  phase  1 and  phase V of  the  ra® Analyzer. 

Once  the  IDS  Analyzer  Is  finished,  the  Internal  Work 
database  Is  no  longer  needed. 

Mork  DBTF  The  database  tables  file  which  describes  to  AOBMS  the 

format  and  contents  of  the  Internal  Work  database. 

See  Appendix  F. 

Error  report  A list  of  all  syntax  and  semantic  errors  appearing  while 

executing  phase  1 of  the  IDS  Analyzer.  See  Appendix  A 
for  a complete  listing. 

Initialization  A report  Indicating  that  the  SDDL  and  Internal  Work 

report  databases  have  been  Initialized  by  AOBMS. 

User  dump  report  Major  output  of  the  IDS  Analyzer  (report-wise).  Contains 

a list  of  the  contents  of  the  SOOL  tables.  Should  be 
used  as  an  aid  In  writing  TDL  (see  Section  4). 

Errors  plus  Any  errors  occurring  during  phase  2 of  the  IDS  Analyzer 

physical  dump  are  printed  along  with  another  report  dumping  all  of 

the  fields  In  the  SDOL  tables. 


5.2  Explanation  of  Processing  Flow 

This  section  comprises  a brief  overview  of  the  algorithms.  Input  and 
outputs  of  the  entire  IDS  Analyzer.  Note  that  the  whole  process  must  be 
performed  once  for  the  source  database(s)  and  again  for  the  target  database(s) 
Each  activity  Is  described  In  turn  with  a complete  JCL  description  given 
In  later  sections. 


Incuts  Outputs 

IDS  directives  to  1.  An  Initialized  temporary  IDS 

e)  create  a temporary  IOS  database 

database 

b)  Initialize  a temporary 

database 

Algorithm 

Three  hundred  sixty  database  pages  have  the  page  header  record  placed 


5.2.2  Activity  2 - Create  IDS  Query  Dictionary 

Inputs  Outputs 

1.  Initialized  temporary  IOS  1.  Complete  IDS  Query  dictionary 

database 

2.  User-prepared  extended  IDS  HD  2.  Execution  report 
section 

3.  IOS  directive  specifying  attributes 
of  the  temporary  database 


Algorithm 

For  purposes  of  the  IOS  Analyzer,  the  Query  dictionary  Is  created  as 


a)  01  records  are  mapped  to  Record  Definition  records. 

b)  02  Items  are  mapped  to  Field  Definition  records  and  the  Immediately 
following  Validation  records. 

c)  03-49  entries  are  mapped  to  Validation  records  which  follow  the 
Validation  record  for  the  02  Item  beneath  which  the  03-49 

entries  appear. 

d)  level  61  entries  are  mapped  to  Description  records  which  are  linked 
to  the  Validation  record  fbr  the  02-49  entry  beneath  which  the 

61  level  appears. 

e)  98  chain  master  entries  are  mapped  to  Haster  Definition  records. 


f)  96  chain  detail  entries  are  mapped  to  Detail  Definition  records. 

There  are  other  record  types  within  the  Query  dictionary  as  well  as  other 
processing,  yet  as  far  as  the  IDS  Analyzer  Is  concerned,  that  Information 
is  Ignored. 


Suppose  that  Figure  5-3  Is  the  extended  HD  section.  Figure  5-4  shows 
the  Query  dictionary  after  activity  two  has  been  executed.  While  It  is 
not  critical  to  understand  completely  how  the  Query  dictionary  Is  constructed. 
It  Is  useful  to  be  familiar  with  the  basic  Record  Definition,  Field  Defini- 
tion, Validation  and  Description  structure  so  that  IDS  Analyzer  errors  can 
be  correctly  Interpreted. 


IDS  QUERY 

01  CITY  TYPE  IS  1 RETRIEVAL  VIA  CALC  CHAIN. 

02  CITY-NAME  PIC  X(15).|| 

. 02  DEPARTMENTS  SIZE  100. 

03  CITY-DEPTS  OCCURS  10  TIMES  SIZE  100 
61  OCCURS  10  TIMES. 

04  DEPT-NAME  PIC  X(10). 


. otter  02-49,  61  entries 
98  CALC  CHAIN  DETAIL  RANDOMIZE  ON  CITY-NAME. 

98  HAS-OFFICIALS  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER. 

01  OFFICIALS  TYPE  IS  2 RETRIEVAL  VIA  HAS-OFFICIALS  CHAIN 


. 02-49  ♦ 61  entries 

98  HAS-OFFICIALS  CHAIN  DETAIL  SELECT  CURRENT  MASTER 


Figure  5-3 

Sample  extended  IDS  MD  section 


5.2.3  Activity  3 - Execute  IDS  Analyzer  Phase  1 

Inputs  Outputs 

1.  IDS  Query  dictionary  created  1.  Partially  complete  SDOL  tables 

In  activity  two 

2.  Runtime  parameters  2.  Internal  work  database 

3-  Scratch  flit  3.  Initialization  report 

4.  IDS  directive  specifying  4.  Error  messages 

attributes  of  Query  dictionary 

Algorithm 

It  Is  Important  to  understand  the  SDOL  tables  format  In  order  to  be 
able  to  read  the  user  report  output  after  activity  four  Is  complete.  Figure 
5-5  Is  the  schema  of  the  SOOL  tables.  Each  record's  contents  art  derived 
as  follows: 

OB  database  name.  All  groups  belonging  to  this  database 

are  along  the  6RPSIN  Set.  All  relations  within  the 
database  are  found  along  the  RELS  Set. 


OFFICIALS 


GROUP  Each  01  record  and  contained- in-repeating  group  has 

a GROUP  record  for  it.  The  relations  of  which  the 
group  Is  a member  are  found  along  the  RELMEM  set. 

The  relations  of  which  the  group  Is  an  owner  are 
found  along  the  RELOWN  set. 

ITEM  Each  user  field  Is  represented  by  an  ITEM  record.  All 

the  ITEMS  for  a GROUP  are  linked  together  on  the  ITEMS 
set.  Set-significant  items  for  a relation  are  linked 
together  via  the  HASSIG  set. 

RELAY  Every  relation  defined  by  the  user  (chain,  concatenated 

match-key  or  phantom  pointer)  has  its  own  RELAY  record. 
The  owner  of  the  relation  is  found  by  heading  the 
RELOWN  set.  The  member  of  the  relation  is  found  by 
heading  the  RELMEM  set. 

The  basic  processing  flow  of  the  IDS  Analyzer  phase  1 follows. 

1.  Start  at  the  first  Record  Definition  record  in  the  Query  dictionary 

a)  Create  a GROUP  record  for  the  01  record. 

b)  Create  RELAY  records  for  all  chains  of  which  this  record  is 
master. 

2.  For  each  Field  Definition  record  of  the  above  Record  Definition 
a)  Create  an  ITEM  record  for  the  02  entry. 


1)  Get  the  Validation  record  if  02  entry  is  for  a group. 

i 1 ) Locate  the  61  OCCURS  Xx  TIMES  and  create  a GROUP  record. 

1 1 i ) Get  succeeding  Validation  records  for  the  Items  of  the 

contained-ln-repeatlng  group.  Create  ITEM  records  for  each 
of  these. 

b)  Link  the  ITEM  records  up  to  the  ITEMS  set. 

For  the  02  TRANSLATION- INFORMATION  and  following  level  61  entries 

a)  Store  primary  key  information  in  Internal  Work  database. 

b)  Create  new  RELAY  records  for  the  specified  phantom  or  match- 

Link  sets. 


key  relations 


The  above  process  is  repeated  for  every  Record  Definition  record.  While  the 
user  is  certainly  not  expected  to  fully  understand  the  details  of  the  IDS 
Analyzer  It  Is  useful  to  have  an  overview  of  the  process  so  that  error 
messages  can  be  interpreted.  Many  details  were  left  out  of  the  above  descrip 
tion  so  that  a basic  picture  can  be  given. 
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5.2.4  Activity  4 - Execute  IDS  Analyzer  Phase  2 


1. 

2. 


Inputs 

iiGjjljjJ&f  'if  ■ 

Outputs 

Internal  Work  database 

1. 

Complete  SDDL  tables 

Partially  complete  SDDL  tables 

2. 

User  dump  of  SDOL  tables 

3. 

Error  messages 

4. 

Physical  dump  of  SDOL  tables 

Algorithm 


During  activity  three,  the  IDS  Analyzer  collected  all  user-supplied 
Information  on  primary  keys  In  the  Internal  Work  database.  Phase  2 of  the 
IDS  Analyzer  takes  this  Information  along  with  the  partially  complete  SDDL 
tables  (all  groups,  relations  and  user  Items)  and  creates  set-significant 
items  for  the  proper  groups.  These  are  then  linked  up  to  the  relations 
(e.g.  sets)  for  which  they  are  significant.  Once  the  entire  SDDL  tables 
file  Is  complete,  the  two  dumps  are  produced. 


5.3  IDS  Analyzer  JCL 


Control  cards  for  executing  all  four  activities  are  illustrated  in 
Figure  5-6.  This  sequence  of  control  cards  is  available  on  the  SYS6EN  tape 
containing  the  Data  Translator  (see  Appendix  S).  Notes  concerning  the 
control  cards  are  stated  below  where  a control  card  Is  not  self-explanatory. 


Line  no. 


Remarks 


0150 


At  this  point,  the  user  file  containing  the  extended 
MD  section  must  be  placed.  Note  that  the  file  must 
be  ASCII. 


0230 


This  is  where  the  R*  file  for  phase  1 of  the  IP? 
Analyzer  is  inserted. 


0280 


Supplied  on  the  SYSGEN  tape  is  a random  library 
containing  a variety  of  Translator  routines  used  by 
multiple  Translator  Main  Modules.  This  file  must  be 
available  at  load  time. 


C290 


Attached  here  is  the  PRMFL  for  the  SDDL  tables  data- 
base file.  See  Section  5.0  for  guidelines  on  creation. 
Note  that  the  SDDL  tables  file  is  different  for  the 
source  and  target  database(s). 


0300 


Supplied  on  the  SYSGEN  tape  is  the  DBTF  for  the  SDDL 
tables  database.  It  must  be  available  at  execution 
time. 


% 

i 


IDEhT 

NOTE  ********************************  *************  ****** 
NOTE  * INITIALIZE  OUFRY  DICTIONARY  * 

NOTE  *************************************************** 
PROGRAM  OIJTI 

FILE  AI.XIS.30S  QUERY  DICTIONARY  FILE 

DATA  I* 

INITIAL  1.360 
DATA  , Q 

CREATE  FC/Al/.RSSZ/360/.RNG/J .360/. INV/NO/ 

NOTE  *************************************************** 
NOTE  * CREATE  IDS  QUERY  DICTIONARY  ★ 

NOTE  *************************************************** 

IDS  NDECK 

SELECTA  EXTENDED  WITH  LEVEL  61  's  »«D  SECTION 

«5S  *?VX,S  QUERY  DICTIONARY 

DA  i A . 0 

CREATE  FC/*3/.HSSZ/360/.RNG/l .360/. INV/NO/ 

NOTE  ****************************** ************  ********* 

NOTE  * EXECUTE  IDS  ANALYZER  PRASE  1 ★ 

NOTE  *************************************************** 

EXECUTE  NREST 

LIMITS  25,  64  .K.-2K,  30000 

PRMFL  R*,R.S, PHASE  1 IDS  ANALYZER  R* 

FILE  H*.X2R.50R 

FILE  AI.X1R  QUERY  DICTIONARY 

data  .q 

CREATE  FC/A1/.SSSZ/360/.RNG/1 .360/. INV/NO/ 

PRMFL  TR.R.R. TRANSLATOR  LIPRAoy 

PRMFL  03/Z1S.W.R.SDDL  TAPLE  FILE 

PRMFL  Q4.D.S.SDDL  DRTF 

FILE  05.X 3R  SCRATCH  FILE 

REMOTE  06  INITIALIZATION  OUTPUT 

FILE  15.X4S. 10P  INTERNAL  WORK  D*TAPASE 

PRMFL  I 6. P.S. INTERNAL  WORK  D«TF 

REMOTE  A3  ERROR  mess  A GEs 

DATA  A5 

SELECT*  RUN-TIME  PARAMETER  FILE 

NOTE  *************************************************** 

wOTE  ★ EXECUTE  IDS  ANALYZER  PRASE  2 

NOTE  *********************************************  ****** 

EXECUTE 

RRMFL  R*. R. S, PHASE  2 IDS  ANALYZER  P* 

FILE  H*.H 1 R. 1 OR 

LIMITS  15. 38K, -IK. 15000 

PRMFL  TR.R.R. TRANSLATOR  L IP°ARY 

FILE  03, Z 1 R SODL  T ARLES 

REMOTE  06  sqdL  DUMP  AND  E&ROP  m£SSa 

REMOTE  07  SQDL  DU»'P 

FILE  I5.X4R  INTERNAL  rtORK  D»TARac= 

END JOB 


z*ao 
rXoO 
0060 
00  70 
0030 
OGRO 
0 1 00 
,110 
3120 
0400 


Figure  5-6 

Complete  IDS  Analyzer  Control  Cards 


Supplied  on  the  SYS6EN  tape  Is  the  OBTF  for  the 
Internal  Work  database.  It  must  be  available  at 
execution  time. 

The  ASCII  file  for  the  run-time  parameter  file 
(described  In  detail  In  Section  5.7)  Is  supplied 
beneath  the  $DATA  A5. 

See  comments  for  line  0230. 


5.4  IDS  Analyzer  - Activity  1 


IOENT 

NOTE  ★★*★★★★*★★★*★*★*★**  ★★■Mr  **★★★**  ★★*****★*★*★*★*  ****★■ 

NOTE  * INITIALIZE  QUERY  DICTIONARY 
NOTE  JHHHHHr 

PROGRAM  OUT I 

FILE  At  «X1S«30R  QUERY  DICTIONARY  FILE 

DATA  I* 

INITIAL  I *360 
DATA  .0 

CREATE  FC/A1 /,BSSZ/360/,RNG/1 ,360/,INV/N0/ 

LUO  Description 

X1S  A temporary  random  file  for  holding  the 

IDS  Query  dictionary.  Must  be  at  least 
30  random  LINKS  In  size. 

— Input  to  QUTI,  specifies  Initialization 

directive  which  must  be  IDS  INITIAL  1 ,360. 

Input  to  IDS,  Indicates  that  a temporary 
IDS  database  Is  being  used.  Directive 
must  be  IDS  CREATE  FC/Al/,BSSZ/360/,RNG/ 
1(360/JNV/N0/. 


3010 
DO  20 
3030 
3400 
0050 
0060 
3070 
3080 
0090 
3100 


IDS 

Fllecode 


Figure  5-7  Is  sample  output  from  QUTI.  It  Is  the  standard  IDS 
Initialization  report.  Be  sure  to  note  that  LLINKS  ALOC-LLINKS  NEC*360 


URECTlVt:  IDS  CRCATE  FC/Al/.BSS?/36«/»RNS/lt360/*lNV/KO/  OOOOOOOO 


5-15 


Any  occurrence  of  an  error  will  be  Indicated  on  report  code  74, 
fllecode  P*.  Typical  errors  are  Incorrect  INITIAL  or  CREATE  directives. 
Appropriate  action  Is  to  correct  and  rerun. 


5.5  IDS  Analyzer  - Actlvli 


Q« 


duo 

0120 

0400 

DUO 

0150 

0160 

0170 

0180 


NOTE 

NOTE 

NOTE 

IDS 

SELECTA 

FILE 

DATA 

CREATE 


Fllecode 

*3 


*S,  S* 


* CREATE  IDS  QUERY  DICTIONARY  * 

+irk*+1Hrkit**1r*+irkirkirk*+*+1i1r*+++1r1rk++irk+*  ******  »»»»★» 

NDECK 

EXTENDED  WITH  LEVEL  6 US  MD  SECTION 

*3,X1S  QUERY  DICTIONARY 

.0 

FC/*3/,BSSZ/360/,RNG/l ,360/, INV/NO/ 

LUO  Description 

X1S  The  Initialized  IDS  Query  dictionary  Is 

populated  by  the  IDS  Translator  In  query 
mode  In  this  activity.  It  must  be 
attached  to  fllecode  *3. 

All  jobs  that  use  a temporary  IDS  data- 
base In  several  activities  must  respecify 
the  IDS  CREATE  directive  for  each 
activity  In  which  the  IDS  database  appears. 
Note  that  the  directive  Is  Identical  to 
the  one  for  activity  one  except  that 
FC/*3/  Is  used  Instead  of  FC/A1/. 

Input  to  IDS  Translator  In  query  mode, 
e.g.,  the  extended  IDS  MO  section.  The 
control  card  sequence  Illustrates  a 
technique  for  Inputting  an  ASCII  file 
containing  the  extended  MD  section  via  a 
SSELECTA  card. 


User  parameters 


The  IDS  Translator  In  query  mode  will  produce  on  report  code  74,  file 
code  P*,  three  sets  of  output. 

a)  A source  listing  plus  errors  of  the  extended  IDS  HD  section. 

b)  A utilization  report  for  fllecode  *3. 

c)  IDS  subroutine  statistics  used  to  create  the  Query  dictionary 
database. 

Only  the  output  for  (a)  Is  Illustrated  In  Figure  5-8. 
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HIS  600  INTEGRATED  DATA  STORE  TRANSLATOR 


82607  02  1Q-28-T6  17.624 


IDS  ALTER  NOS 


01  THE-UNIVERSE  TYPE  IS  l 
retrieval  VIA  calc  Chain 


00001 

00002 

00003 

00004 
00004 
00006 
00007 


02  THE-GALAXIES  OCCURS  2 TIMES  SIZE  46. 
61  OCCURS  2 TIMES. __  _ 

03  nilkyway  pic  xis>. 

03  ANDROMEDA  pic  X<5). 

03  NUMBER  OF  STARS  PIC  9(8>  COMP-1 


00009 

00010 
00011 
00012 
GG013 


02  THE-DZPPERS  PIC  X(20>  OCCURS  2 TIMES 


61  OCCURS  2 TIMES 


02  SOLAR-SYSTEMS  Ptr „X t 30 > 


02  RSTEROIOS  SIZE  72  ». 


61  OCCURS  3 TIMES 


00016 

00017 


61  OO-NOT-RESTRUCTyRE 


04  STATES-IN-COIINTRIES  PIC  X(10) 
04  CITIES-IN*STATES  PIC  XtlO). 


00031 

00032 


3”  TIRES  SIZE" 16 


61  OCCURS  3 TIMES. 

OS  THE-GOOC  PIC  XI2) 


00034 

00035 


os  -the-ugly  PiC  X ( 2 ) 
61  EQG. 


00037 

00036 


61  EOS. 

02  translation-information 


00042 


61  It  UNIVERSE-NAME 
61  G:  THE-GALAXICS « 


00044 

00045 


00046 

00047 
30046 


61  THE-UNIVCRlE/OVNS/THC-GA 
61  LAXICS. 


00049 

00050 
00041 


6i  c-k-f: 

61  THC-UNIVERSE/OMNS/THE-OI 


0052 


Figure  5-8 
Activity  2 Output 


00019 

00020 

04  ROCK-SPECIFIC-GRAVITY  PIC  9112)  COMP-2. 
61  COG. 

00021 

00022 

00023 

02 

61 

61 

PLAfiETS'-bF-tHC-SUM  OCCURS  TIMES  SIZE- 90. 

OCCURS  9 TIMES. 

OO-NQT-RESTRUCTURE . 

Hum 

83  NARC-OF  -PLARCt  PIC  XTT8IT 

00025 

61 

eog. 

00026 

02 

HEmISPHCRES-OF-EArTH  OCCURS  2 TIMES  SIZE  390. 

00028 

03 

CONTINENTS  PIC  X(5>. 

30029 

OS 

COWNTRIES-ON-CONTINENTS  OCCURS  5 TIMES  SIZE  190 

00030 

51 
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1 


] (260 T 02  10-28-76 

IDS  ALTER  NOS* 


17*624  his  60o  Integrated  oata  stcre  translator  :sr  i A 


IJ0053 
00054 

nooss 

>056 
00057 


61  65  HENlSPHERES*OF*EARTH* 

6i  e-k-f: 

6r-THt«tmJvc*se/owNs/we*isP 

61  HERFS-* 

6i  g; 


*6058 — ~ 


I !0G59  * 
00060 
00061  * 

1 | GU62 
(JO  063 
00064 

Q0065 
0066 

00067 ' *— 
,40060 

Hhepe  WFRE 


*»C©NTInEN*S« 

6i  e-k-f; 

61  HEMISPHERES-/OWNS/COUNTR 
-61  1ES-0N*  - — 

6i  g: 

61  inhabxtants-of-cittes* 


61 


E»K*»Fi 


61  COU(aTRIES«ON/OWNS/lNHABI 
61  TANTS-. 

-96— CALC  CHAIN- DETAIL 


RANDOMIZE  on  UNXVrRsE-NAME. 

oooooi  warning  flags  in  tmf  above  ids  translation 


Ji 

0 


0 


Figure  5-8  (cont'd) 
Activity  2 Output 


Error  Output 


Any  flagrant  or  easily  detectable  syntax  errors  are  denoted  by  the  IDS 
Translator  In  query  node.  All  are  self-explanatory.  Cannon  errors  are: 

1.  REQUIRED  IDS  QUERY  CARD  MISSING 

Cause:  User  did  not  Include  the  IDS  QUERY  card  as  the  first  line  of  the 
extended  IDS  NO  section.  Alternatively,  the  rigid  format  of  IDS 
Query  starting  In  column  8 was  not  observed. 

Action:  Correct  and  rerun. 

2.  SIZE  OR  PICTURE  CLAUSE  MISSING  FROM  ABOVE  02 

Cause:  Either 

. a)  A "SIZE  0"  was  not  added  to  an  02  TRANSLATION- INFORMATION 
entry,  or 

b)  An  02  COBOL  group  was  defined  without  a SIZE  clause.  See 
Section  3.2.1  for  rules  In  placing  SIZE  clauses. 

Action:  Correct  and  rerun. 

Some  errors,  detectable  by  the  IDS  Translator  In  normal  mode,  cannot 
be  detected  by  the  IDS  Translator  In  query  mode.  These  errors  will  lead 
to  unpredictable  results.  The  following  Is  a known  list  of  errors  that 
are  not  detected  by  the  IDS  Translator  In  query  mode  with  the  corresponding 
known  result. 

Error  In  extended  MD  Section  Result  of  non-detection 

1.  A loop  (or  cycle)  defined  1.  18-RUNTIME-EXHAUSTED  In  activity 

with  96  CHAIN  MASTER  and  two. 

9B  CHAIN  DETAIL  entries. 

2.  An  elementary  Itw  whose  size  2.  18-RUNTIME  EXHAUSTED  In  activity 

Is  larger  than  maximum  three.  Impossible  to  detect  in 

allowable  by  IDS.  activity  three  since  Query  dictionary 

Is  built  Incorrectly. 

3.  A 03-49  entry  that  Is  not  3.  Incorrect  IDS  Analyzer  output.  The 

placed  underneath  an  02  entry.  Validation  record  for  the  errant  03-49 

entry  Is  placed  underneath  a Field 
Definition  record  belonging  to  an 
entirely  different  record  type. 


5.6  IDS  Analyzer  - Activity  3 


3190 

3200 

3400 

3210 

3220 

3230 

3240 

3250 

3260 

3270 

3280 

3290 

3300 

33.10 

3320 

3330 

3340 

3350 

3360 

3370 


note  **★★★****★★★★*★★★★★*★★★★★*★»★*****»*»*»**  **»»***»'»* 

NOTE  * EXECUTE  IDS  ANALYZER  PHASE  1 * 

NOTE  ******* *********************** ** *******  ******  ****** 

EXECUTE  NREST 

LIMITS  25,64  K.-2K. 30000  USE  APPROPIATE  CORE  RECKMNT 

PRMFL  R*,R,  S, PHASE  I IDS  ANALYZER  R* 

FILE  H*,X2R«50R 

FILE  AI.XIR  QUERY  DICTIONARY 

DATA  . Q 

CREATE  FC/AI/,BSSZ/360/,RNG/l ,360/, INV/NO/ 

PRMFL  TR , R , R , TRANSLATOR  LIBRARY 

PRMFL  03/Zl S,W,R,SDDL  TABLE  FILE 
PRMFL  04,R,5,5DDL  DBTF 
FILE  05.X3R 
REMOTE  06 
FILE  1 5,X4S« I OR 
PRMFL  1 6, R,S, INTERNAL  WORK  DBTF 
REMOTE  A3 
DATA  A5 

SELECTA  RUN-TIME  PARAMETER  FILE 


SCRATCH  FILE 
INITIALIZATION  OUTPUT 
INTERNAL  WORK  DATABASE 


Description 

Phase  1 IDS  Analyzer  R*  file  from  the 
SYS6EN  tape. 


Required  fllecode  so  an  entry  can  be 
made  In  PAT.  Must  be  a random  temporary 
file. 

IDS  Query  dictionary  file  Initialized  In 
activity  1 and  populated  In  activity  two. 
After  activity  three.  Its  presence  Is  no 
longer  required,  hence,  the  disposition 
of  "R". 

Directive  to  IDS  describing  the  attributes 
of  the  temporary  IDS  Query  dictionary 
database.  Its  format  is  Identical  to 
the  directive  In  activity  one. 

Random  library  of  Oata  Translator  object 
routines.  Available  on  SYSGEN  tape. 

A permanent  random  file  used  to  contain 
the  SOOl  tables  for  the  database  descrip* 
tlon(s)  processed  by  the  IOS  Analyzer. 

See  Section  5.0  for  guidelines  on  choosing 
a size. 


Description 

Obtained  from  the  SYSGEN  tape,  the 
database  tables  file  (DBTF)  for  the 
SDDL  tables  database  must  be  attached  to 
fllecode  04.  See  Appendix  F for  a 
description  of  the  role  of  DBTFS 

A null  scratch  file  that  ADBNS  uses. 

Initialization  and  some  error  output 
for  activity  three. 

Random,  temporary  file  for  holding  the 
Internal  Work  database.  10  random  LINKS 
are  sufficient  for  the  largest  extended 
HD  section.  Must  have  disposition  of 
Save  since  It  Is  used  In  activity  four. 

Similar  to  fllecode  04  Is  the  DBTF  for 
the  Internal  Work  database.  It  Is  avail- 
able from  the  SYSGEN  tape. 

Error  message  output  from  phase  1 of  IDS 
Analyzer. 

Run-time  parameter  file  (described  below) 
Is  selected  here  Into  $DATA  A5.  It  must 
always  be  available. 


Fllecode 


User  parameters 

For  fllecode  A5,  the  user  must  supply  a run-time  parameter  file  with 
format  as  follows: 


* dbtype-1  * database  name-1 
record-name-1  for  database  name-1 
record- name- 2 " " " 


record-name-n  for  " " 

* dbtype-2  * «-  database  name-2 

record-name-1  for  database  name-2 
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column:  1 2 3 4 5 6 30  35 

record-name-n  for  database  name-2 


* dbtype-5  * database  name-5 
record-name-1  for  database  name-5 


record-name-n  for  database  name-5 


Rules: 

1.  For  each  database  being  described  via  one  combined  extended  IOS  MD 
section  (see  Section  3.8),  the  name  of  the  database.  Its  type  and 
the  records  which  belong  to  the  database  must  be  specified.  This 
Is  necessary  so  the  IDS  Analyzer  has  a way  to  tell  which  01  record 
within  a combination  of  several  database  descriptions  belongs  to  a 
given  database. 

2.  dbtype-1  ...  dbtype-5  must  be  either  IDS,  ISP,  or  SEQ  and  must  be 
enclosed  by  In  columns  1 and  5. 

3.  database-name-1  . . . database  name-5  can  be  any  name  (up  to  thirty 
characters  In  length)  with  no  preceding  blanks  which  Is  assigned  as 
the  database  to  which  the  succeeding  record  names  will  belong. 

4.  record-name-1  ...  record-name-n  are  names  (up  to  thirty  characters 
In  length)  which  must  be  01  entries  within  the  extended  IDS  MD 
section.  No  preceding  blanks  are  allowed. 

Example 

Suppose  a user  wishes  to  describe  three  source  databases  (one  ISP,  two 
IDS)  with  one  combined  extended  MD  section.  Each  database  contains  the 
following  records: 

ISP  IDS  fl  IDS  #2 

INVENTORY  AIRCRAFT  PEOPLE 

WAREHOUSE  MANUFACTURERS  ADDRESS-OATA 

SHIPS 


The  run-time  parameter  file  would  then  be 

*ISP*INVENTORY-DATA-BASE 

INVENTORY 

WAREHOUSE 

*IDS*AIRCRAFT-SHIPS 

AIRCRAFT 

MANUFACTURERS 

SHIPS 

*IDS*PEOPLE-DATA-BASE 

PEOPLE 

ADDRESS-DATA 


Examples  of  output 

Figure  5-9  Is  the  Initialization  report  for  the  ADBMS  database  initializer 
As  noted  In  Appendix  F of  the  User  Manual,  each  ADBMS  database  (In  this  case 
the  SDDL  tables  and  Internal  Work  database)  Is  divided  Into  1024  word  pages 
and  must  be  Initialized  prior  to  storing  records  In  them. 

Figure  5-10  Is  a sample  of  some  error  output  produced  by  the  IDS  Analyzer. 
The  error  message  Is  printed  followed  by  the  IDS  Analyzer's  current  location 
within  the  IDS  Query  dictionary. 

Error  Output 

See  Appendix  A for  a complete  list  of  errors  with  their  causes  and 
appropriate  actions. 


5.7  IDS  Analyzer  - Activity  4 


NOTE  ♦ ft*  * »* 

NOTE  * EXECUTE  IDS  ANALYZER  PHASE  2 * 

NOTE 

EXECUTE 

PRMFL  R*,R,S, PHASE  2 IDS  ANALYZER  R* 

FILE  H*«H1R, IOR 

LIMITS  15, 38K, -IK, 15000  USE  APPROPIATE  CORE  REQ'MNT 

PRMFL  TR,R,R, TRANSLATOR  LIBRARY 

FILS  03.Z1R  SuDL  TABLES 

REMOTE  06  SDOL  DUMP  AND  ERROR  MESSAGES 

REMOTE  07  SDDL  DUMP 

FILE  1 5 ,X4R  INTERNAL  WORK  DATABASE  s 

END JOB 


3380 

3390 

3400 

3410 

3420 

3430 

3440 

3450 

3460 

3470 

3480 

3490 

3500 


SNUMB  * 82&0T « ACTIVITY  U s 03» 


initialize  scdl  TABLES  database* 


DBIN 


10/28/76  00  ia.319 


data  base  initialized  WITH  37  pages. 
INITIALIZE  internal  tables  database. 


DBIN 


10/28/76  QQ  16,022. 


DATA  RaSE  INITIALIZED  WITH  18  PAGES. 


Figure  5-9 

Initialization  Output  - Activity  3 


sNUMB  = 8260T»  ACTIVITY  * = 03*  REPORT  COOE  s Q3«  RECORC  COUNT  = 000027 


IDS  ANALYZER  ERROR  REPORT 

lth*2ir»*7-6 ' • ■"  "■  1 

*#*ERROR...sIZE  CONFLICT  BETWEEN  LENGTH  OF  GROUP  AND  LENGTHS  OF  ELFMENTARY  Items 
CURRENT  DATa-BASE  ISs  COS jIC-DATABAsE 

CURRENT-Ol-RECORt) IS-THF-UftlVERSE  ~ 

CURRENT  02  field  IS=  ThF-GALAXlFS  1 

current  VALIDATION  Is=  nlmper 

CURRENT— frl~tEVEL Is—  EC  G. 

•*#ERROP...slZE  CONFLICT  BETWEEN  LENGTH  0 F GROUP  AND  LENGTHS  OF  ELFMENTARY  ItE 
CURRENT  OATa-BASE  IS=  CCs^IC-DATABAsE 

CURRENT  -W-^EGORO — IS=-THE-UN*VERSE 

CURRENT  02  FIELD  IS=  ASTFRO*DS 

current  validation  is=  rcck-s^ecific-gravity 


***ERROR...sIZE  conflict  BETWEEN  LENGTH  pF  GROUP  AND  LENGTHS  OF  ELFMENTARY  TTEwf 
CURRENT  OATa-BASE  Is=  COSMIC-DATABASE 

CURRENT  02  FIELD^  I$=  ASTFROlDS^ 

CURRENT  VALIDATION  IS=  RCCK-SpECIFIC-GRAVITY 


***FRRGR...sIZE  CONFLICT  BETWEEN  LENGTH  oF  GROUP  AND  LENGTHS  OF  ELFMENTARY  ItE» 

current  oata-base  is=  ccs«ic-database 

CURRENT  02  FIELD  IS=  ASTFRQlOS 


current  validation  is=  rcck-sfecific-gravity 


-CURRENT-M-bEVEL- — ISa-EGG-.- 


Flgure  5-10 

Output  Activity  3 - Report  code  03 


Description 

Phase  2 IDS  Analyzer  R*  file  available 
from  the  SYSGEN  tape. 


Fllecode 


Fllecode  required  so  that  an  entry  can  be 
made  In  PAT.  Must  be  a random  temporary 
file. 

Random  library  of  Translator  object 
routines.  Available  on  SYSGEN  tape. 

SDDL  tables  database,  partially  completed 
In  activity  three. 

Error  report  and  physical  dump  of  SDDL 
database. 

User  dump  of  SDDL  tables  database. 

Internal  Work  database  from  activity 
three. 


Example  of  output 

Figure  5-12  Is  an  example  physical  SDDL  table  dump  appearing  on  report 
code  06.  The  user  need  not  be  concerned  with  Interpreting  this  output 
because  It  Is  used  only  for  debugging  purposes. 

However,  Interpretation  of  the  user  SDDL  table  dump  Is  critical  to 
successful  translation  (see  Figure  5-13  for  an  example).  The  output  Is 
organized  as  follows: 

1.  Each  database  Is  listed. 

a)  for  every  database,  the  groups  within  It  are  listed. 

b)  •>  for  every  group,  the  Items  within  the  group  and  the  relations 

of  which  the  group  Is  a master  or  detail  are  listed. 

2.  All  relations  defined  are  listed. 

a)  for  each  relation,  the  master  and  detail  group  of  the  relation 
are  printed. 

3.  All  relations  whose  owner  (master)  Is  a SYSTEM  are  listed. 

For  Illustrative  purposes,  a partial  extended  IDS  MD  section  Is  shown 
In  Figure  5-11.  The  corresponding  output  produced  by  the  IDS  Analyzer  Is 
shown  In  Figures  5-12  and  5-13.  Each  field  of  the  user  SDDL  table  dump  Is 
explained  below  with  reference  to  the  example  extended  MD  section. 


01  ADMINISTRATION  TYPE  IS  3 RETRIEVAL  VIA  CALC  CHAIN. 

02  AOMIN-NUM  PIC  X(3). 

02  INAU6-0ATE  SIZE  16. 

03  MONTH  PIC  X(10). 

03  OAYE  PIC  9(2). 

03  YEAR  PIC  9(4). 

02  VICE-PRESIDENT  SIZE  20. 

03  NAME-FIRSTN  PIC  X(10). 

03  NAME-LASTN  PIC  X(10). 

02  ADMITTED-STATES  SIZE  96 

03  STATE-DREF  PIC  9(6)  COMP-1  OCCURS  6 TIMES 

61  OCCURS  6 TIMES 

61  EQG. 

03  ST-NAME  PIC  XOO)  OCCURS  6 TIMES 

61  OCCURS  6 TIMES. 

61  DO-NOT-RESTRUCTURE 

61  EOG. 

02  TRANSLATION- INFORMATION  SIZE  0. 

61  PRIMARY  KEYS. 

61  GROUP: 

61  ADMINISTRATION, 

61  ITEMS:  ADMIN-NUM. 

61  GROUP: 

61  STATE-DREF, 

61  E-K-F: 

61  AOMINISTRATI/OMNS/STATE- 

61  DREF. 

96  CALC  CHAIN  DETAIL  RANDOMIZE  ON  ADMIN-NUM. 

98  STATES- ADMITTED  CHAIN  MASTER  CHAIN-ORDER  IS  AFTER. 

98  P-A  CHAIN  DETAIL  SaECT  CURRENT  MASTER 


Figure  5-11 

Example  extended  MD  section 


UNIVERSITY  OF  MICHIGAN  SDDL  TABLE  DUMP  (VERSION  II A,  RELEASE  2) 


Figure  5-12  (cont'd) 
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] IDS  DATABASE 

i 

The  name  of  the  database  for  wMch  the  output  below  Is 
collected.  Each  database  defined  within  the  combined 
extended  MO  section  Is  printed.  Note  that  this  name 

Is  the  same  as  that  supplied  on  the  run-time  parameter 
file. 

IDS  NAME 

User  names  supplied  In  the  extended  MO  section.  The 
user  refers  to  these  names  In  writing  the  TDL. 

ADBMS  NAME 

Every  user  name  has  a corresponding  six  character 

ADBMS  name.  In  some  Translator  error  messages,  the 

ADBMS  name  Is  output,  hence,  this  listing  Is  a useful 
cross-reference  tool. 

DISPL. (CHAR) 

Displacement  In  characters  of  the  group  (If  a contalned- 
in-repeating  group)  or  Item.  Note  in  the  example  that 
ADMIN-NUM  starts  at  location  ten  (10)  since  there  are 
nine  characters  taken  up  by  the  IDS  record  header. 

STORAGE  CONSTRUCT 

H v - m r T-  , 

For  items,  the  storage  representation  is  printed;  for 
relations,  the  relation  type  is  denoted.  Possible 
relation  types  are; 

CONCAT  - concatenated  relations 

CHAIN  - phantom  pointers  or  IDS  chains 

MTCHKY  - Match- key  relations 

Note  that  items  that  are  PIC  99  are  printed  as 
a 1 phanumerl c-type . 

PAD-CHAR 

By  default,  alphanumeric  items  have  a pad  character 
of  blank;  computational  items  have  a pad  character  of 
zero.  This  can  be  overridden  by  use  of  the  U61  PAD" 
entry,  however. 

IDS/RIF  LENGTH 

The  first  number  to  the  left  of  the  slash(/)  Is  the 
length  In  characters  of  the  Item  In  the  IDS  database. 
This  should  agree  with  the  user's  view  of  the  database. 
The  number  to  the  right  of  the  slash  Is  the  length  in 
characters  of  the  Item  as  It  Is  represented  In  the  RIF. 
Note  that  all  Integers  are  single  precision  In  the  RIF 
and  all  floating  point  Items  are  double  precision  in 
the  KIT. 

VALUE 

For  IDS  records,  this  Is  the  number  specified  by  the 

TYPE  IS  clause.  For  ISP  and  sequential  database  records 
the  character  string  specified  by  the  61  IDENT  entry  Is 
printed.  Note  that  contalned-ln-repeatlng  groups  do  not 
have  a value.  The  Reader  Identifies  contalned-ln- 
repeatlng  groups  by  their  displacement  within  their 
"containing"  groups. 

♦KEY* 

To  the  left  of  any  Item  which  was  declared  to  be  a 
primary  key  is  the  Indication  of  *KEY*. 

♦S-S-KEY* 

1 

Any  set-significant  Items  defined  in  the  EXTERNAL- KEYS- 
FROM  level  61  will  be  denoted  as  a set-significant-key 
(S-S-KEY). 

5-35 


*SET-SIG*  All  set-significant  Item  for  the  group  are  Identified 

by  *SET-SI§*  If  they  are  not  prlwary  key**  I"  the 
exwaple,  because  ADMINISTRATION  Is  a detail  of  the 
relation  P-A  (whose  waster  has  three  prlaary  keys; 
LASTN,  FIRSTN,  INIT),  three  set-significant  Itews  wist 
be  present  within  ADMINISTRATION.  Note  that  they  are 
not  physically  present,  only  logically.  Their  nawes 
are  constructed  according  to  the  rules  given  In  Section 
3.2.3  of  the  User  Manual. 

MASTER  OF  Each  relation  of  which  the  group  Is  a waster  Is  listed 

along  with  the  corresponding  AD8MS  nawe  and  relation 
type.  Note  In  the  exawple  the  construction  of  the 
concatenated  relation  nawe  frow  ADMINISTRATION  to 
STATE-DREF. 

DETAIL  OF  Each  relation  of  which  the  group  Is  a detail  Is  listed 

along  with  the  corresponding  AOBMS  nawe  and  relation 
type.  Note  In  the  exawple  that  since  ADMINISTRATION  Is 
a CALC  record.  It  wust  be  a detail  of  a relation  (whose 
owner  Is  SYSTEM)  named  CALC-AOMINISTRATION. 

After  all  the  groups  within  each  database  have  been  printed,  the  last  few 
pages  of  the  report  give  a summary  of  all  the  relations  (In  alphabetical 
order)  represented  within  the  SOOL  tables  In  question.  Lastly,  all  system 
entry  relations  are  listed  for  useful  reference. 
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6.0  RUNNING  THE  TDL  ANALYZER 

After  the  user  has  created  both  the  source  and  the  target  Stored  Data 
Definition  Language  (SDDL)  tables.  It  Is  necessary  to  supply  the  Translator 
with  a description  of  the  mapping  (restructuring)  to  be  performed  by  the 
Restructures  This  Is  done  by  supplying  the  Translation  Definition 
Language  (TDL)  Analyzer  with  a textual  description  of  the  mapping.  The 
TDL  Analyzer  then  produces  tables  which  are  used  by  the  Restructurer  to 
perform  the  mapping.  The  general  processing  flow  of  the  TDL  Analyzer  Is 
as  follows: 

1.  Make  temporary  copies  of  the  source  and  target  SDDL  tables. 

2.  Analyze  the  TDL  description  and  produce  the  TDL  tables. 

3.  Post-process  the  tables  by  Including  Information  which  Improves 
the  run-time  performance  of  the  Restructurer. 

4.  Optionally  give  a user-friendly  dump  of  the  TDL  tables. 

Before  executing  the  TDL  Analyzer,  the  following  steps  must  be  performed: 

1 . The  IDS  Analyzer  must  be  run  to  produce  source  and  target  SOX 
tables  (see  Section  5.0  for  a description  of  this  process). 

2.  A valid  TDL  description  must  be  written  (see  Section  4.0  for  a 
description  of  this  process). 

3.  A permanent  file  (random)  must  be  created  to  hold  the  TDL  table 
database.  A rule  of  thumb  to  use  for  determining  the  size  of 
this  file  Is  to  use  18  11 Inks  or  one-half  the  size  of  the  target 
SDDL  database,  whichever  Is  greater.  This  formula  will  usually 
supply  a TDL  table  size  which  Is  slightly  larger  than  needed. 

6.1  Detailed  Overview  of  TDL  Analyzer  Execution 

Executing  the  TDL  Analyzer  requires  the  five  activities  shown  below: 

1.  Make  temporary  copies  of  the  source  and  target  SDDL  tables. 

2.  Execute  the  TDL  Analyzer  to  produce  the  TDL  tables. 

3.  Post-process  the  TDL  tables  with  the  Sysacc  builder. 

4.  Post-process  the  TDL  tables  with  the  Compatibility  builder. 

5.  Optionally  give  a user-friendly  dunp  of  the  TDL  tables. 

The  entire  process  Is  Illustrated  In  Figure  6-1;  the  components  are  dis- 
cussed below. 

UTILITY  The  GCOS  utility  program.  See  the  UTILITY  manual 

for  a description  of  the  output  and  error  reports 
generated  by  this  module. 

SOURCE  and  TARGET  SDOL  TABLES  AD6MS  databases  produced  by  the  IDS 

Analyzer  which  contain  the  Data  Translator's 
descriptions  of  the  source  and  target  databases. 

SCRATCH  COPY  SOURCE  and  TARGET  SDOL  TABLES  Temporary  files  which 

contain  copies  of  the  source  and  target  SDDL 
tables. 


i 


I 

Is 


UTILITY  REPORT 


A report* on  the  success  or  failure  of  the 
utility  program. 


Figure  6-1 

TDL  Analyzer  Components 
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0 

TDt  ANALYZER  An  R*  file  containing  the  object  version  of  the 

* * TDl  Analyzer. 

TDL  PARSE  TABLES  A file  which  contains  the  TDL  parsing  tables. 

TOL  description  The  user-written  TDL  description. 


SDDL  DBTF  The  database  tables  file  describing  to  ADBMS 

the  format  and  contents  of  the  SDDL  tables 
databases.  See  Appendix  F. 

TDL  Tables  An  ADBMS  database  containing  the  Data  Translator 

representation  of  the  restructuring  mapping. 

TDL  D61T  The  database  tables  file  describing  to  ADBMS  the 

format  and  contents  of  the  TDL  tables  database. 
See  Appendix  F. 

LISTING  AND  ERRORS  A listing  (If  requested)  of  the  TDL  description, 

user  errors  and  Warnings,  and  a statistical 
summary  of  the  TDL  Analyzer  execution. 


POST  PROCESS  I - SYSACC  An  R*  file  containing  the  object 

version  of  the  first  post-process. 

POST  PROCESS  II  - Compatibility  An  R*  file  containing  the  object 

version  of  the  second  post-process. 

TDL  Dump  Program  An  R*  file  containing  the  object  version  of  the 

program  which  produces  the  user  dump  of  the  TDL  ' 
tables. 


USER  DUMP  OUTPUT  The  user  dump  of  the  TDL  tables. 


This  section  comprises  a brief  overview  of  the  TDL  Analyzer.  Each 
activity  Is  described  In  turn  with  a complete  JCL  description  given  In 
later  sections. 

The  TDL  Analyzer  operates  by  sequentially  reading  each  card  Image  In 
the  TDL  description.  Each  card  Image  Is  the  checked-for  syntax  and 
semantic  errors.  If  no  errors  are  found,  the  SDDL  tables  are  accessed 
and  entries  are  made  In  the  TDL  tables  (when  appropriate). 


TDL  Analyzer  JCL 


Control  cards  for  executing  all  five  TDL  Analyzer  activities  are 
Illustrated  In  Figure  6-2.  This  sequence  of  control  cards  Is  available 
on  the  SYSGEN  tape  containing  the  Data  Translator.  Each  activity  Is 
described  below: 


6-4 


1010 

*$ 

IDENT 

1020 

* S 

NOTE 

*****  ************  a*  a*  ***  ******  *******  ******** 

1030 

$ 

NOTE 

* 

* 

1040 

$ 

NOTE 

* COPY  SOURCE  AND  TARGET  SDDL  TABLES 

* 

1050 

$ 

NOTE 

* 

* 

1060 

$ 

NOTE 

★♦★»*★★★*★★  ****************************  ****** 

1070 

$ 

UTILITY 

1080 

$ 

. - FUTIL 

14,15,  RWD/.1 4/ , RCOPY/ 1 F/ 

1090 

$ 

PRMFL 

1 4, R,R, SOURCE  SDDL.  DATA  BASE  FILE 

1100 

$ 

file 

1 5, X IS, SIZE  OF  SOURCE  SDDL  DATA  BASE  FILE 

IN  LINKS 

1110 

$ 

FUTIL 

16, 1 7 , RND/ 1 6/ , RCOPY/ 1 F/ 

1 120 

$ 

PftMFL 

1 6, R, RETARGET  SDDL  DATA  BASE  FILE 

4130 

$ 

FILE 

1 7.X2S.SIZE  OF  TARGET  SDDL  DATA  BASE  FILE 

IN  LINKS 

1140 

$ 

NOTE 

******* ************************** ******  ****** 

1150 

$ 

NOTE 

* 

>* 

1 160 

$ 

. NOTE 

* EXECUTE  TDL  ANALYZER 

* 

1170 

$ 

. NOTE 

* 

* 

1180 

$ 

NOTE 

********************************************* 

1190 

$ 

EXECUTE 

NREST 

1200 

$ 

LIMITS 

XX,46K,-3K,XX  USE  APPROPRIATE  LIMITS 

1210 

$ 

PRMFL  ... 

R.*,R,S,TDL  RSTAR  PILE 

1220 

$ 

FILE 

H*,Z1R,40R 

1230 

$ 

PRMFL 

04, R, S,TDL  PARSE  TABLES 

1240 

$ 

SATA 

02,, COPY 

?25Q 

$ 

SELECTA  TDL  DESCRIPTION 

1260 

$ 

. ENDCOPY 

1270 

$ 

NOTE 

ANALYZER: OUTPUT  IS  ON  FILE  CODE  06 

1280 

$ 

FILE 

07,X!R 

1290 

$ 

FILE 

09,X2S 

1300 

$ 

nRMFL 

1 1 ,W,R,TDL  DATA  BASE  FILE 

1310 

$ 

PRMFL 

1 2, R, S,ADBMS  TABLE  FILE  FOR  TDL  TABLES 

1320 

$ 

FILE 

13, NULL 

1330 

$ 

FILE 

14, NULL 

1340 

$ 

PRMFL 

TR,R,R, TRANSLATOR  LIBRARY 

1350 

$ 

IF 

18, IF  IF  TDL  ERRORS  THEN  SKIP  TO  DUMP 

1360 

$ 

NOTE 

★★★★★»★*★★**»★**★******★**★*★★**»*****»****** 

1370 

$ 

NOTE 

* - 

* 

1380 

$ 

NOTE 

* • POST  PROCESS  I - SYSACC  BUILDER 

* 

1390 

$ 

. . NOTE 

* 

* 

1400 

$ 

NOTE 

****»»***»*********»»*****»*********★**.***>*★ 

1410 

. .EXECUTE 

NREST 

1420 

$ 

. LIMITS 

XX , 33K , -3K , XX  USE  APPROPRIATE  LIMITS 

1430 

% 

PRMFL 

R*,R, S, SYSACC  BUILDER  RSTAR  FILE 

1440 

t 

RRMFL 

07,M,R.,TDL  DATA  BASE  FILE 

Figure  6-2 

TDL  Analyzer  Prototype  JCL 


.... 


, Ub 


1440 

t 

PRMFL 

07«N,RVTDL  DATA  BASE  FILE 

1450 

$ 

FILE 

08.X2S 

1460 

$ 

• PRMFL 

TR  ,R  *R,TRAN SLATOR  L I BINARY 

1470 

t 

NOTE 

********  ***  * * **********  ***********■*******+*** 

1480 

$ 

NOTE 

* 

* 

1490 

$ 

NOTE 

* POST  PROCESS  .11  - COMPATIBILITY  BUILDER 

* 

1500 

$ 

NOTE 

* 

* 

1510 

$ 

NOTE 

***************************  ************.**i **** 

1520 

$ 

•EXECUTE  NREST 

1530 

$ 

LIMITS 

XX«52K«-3K,XX  USE  APPROPRIATE  LIMITS 

1 540 

$ 

PRMFL 

R*« R • S«  COMPAT 1 8i L I TY  RSTAR  FILE 

1550 

$ 

PRMFL 

07,M,R,TDL  DATA-BASE  FILE 

1560 

$ 

FILE 

08.X2S 

1570 

$ 

PRMFL 

TR,RfR,TRANSLATOR  LIBRARY 

1580 

$ 

NOTE 

1590 

NOTE 

* 

* 

1600 

NOTE 

* TDL  TABLE  DUMPER. 

* 

1610 

$ 

NOTE 

* 

* 

1620 

$ 

NOTE 

********************************.************* 

1630 

1 

IF 

1 9 ♦ ENDJOB  SC  IP  DUMP  IF  NOT  REQUESTED 

1640 

$ 

EXECUTE 

NREST 

1650 

s 

LIMITS 

XX,25K,-3K,XX  USE  APPROPRIATE  LIMITS 

1660 

t 

PRMFL 

R*«R«StTDL  DUMPER  RSTAR  FILE 

1670 

$ 

PRMFL 

02«R*R«TDL  DATA  BASE  FILE 

1680 

s 

NOTE 

DUMP  .OUTPUT  IS  ON  FILE  CODE  06 

1690 

$ 

PRMFL 

TR*R fR, TRANSLATOR  LIBRARY 

1700 

$ 

ENDJOB 

D 

0 

o 

o 


Figure  6-2  (cont.) 
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6.4  TOL  Analyzer  - Activity  1 


1020  $ 

NOTE 

irk 

1030  $ 

NOTE 

k 

1040  $ 

NOTE 

k 

1050  $ 

• NOTE 

k 

1060  $ 

NOTE 

kk 

1070  $ 

UTILITY 

1080  $ 

.FUTIL 

14 

1090  $ 

PRMFL 

.14 

1100  $ 

FILE 

15 

1110  $ 

FUTIL 

16 

1120  $ 

PRMFL 

16 

1130  $ 

FILE 

17 

Fllecode 

COPY  SOURCE  AND  TARGET  SDDL  TABLES 


* 

♦ 

* 


14 

16 

18 

17 


LUD 

Description 

- 

Source  SDDL  tables 

- 

Target  SDDL  tables 

XI S 

Scratch  copy  of  source 

X2S 

Scratch  copy  of  target 

Example  of  Output 


Figure  6-3  Is  a sample  of  a successful  execution  of  activity  1.  The 
report  Is  generated  by  the  UTILITY  program  on  report  code  53.  If  the 
UTILITY  operation  Is  not  successful,  then  a message  Indicating  the  problem 
will  be  printed.  These  messages  are  described  In  the  UTILITY  manual. 


Discussion 


Activity  one  makes  temporary  copies  of  the  source  and  target  SDDL 
tables.  The  user  should  enter  the  file  names  of  the  source  and  target 
SOOL  tables  where  Indicated  on  lines  1090  and  1120  respectively.  The 
sizes  of  these  files,  rounded  up  to  the  closest  link  (12  11 Inks)  should 
be  entered  where  Indicated  on  lines  1000 and  1130. 


rVl 


U 
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U 1 


u 


1 


a 

m 
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D 

DI 
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UTILITY  REPORT  750204 


PAGE 


* „QX/nFUTIL  ,4»  >5,Rf<D/|4/.RC0PY/IF/ 

RCOPYD  1 FILE 

* n FLTIL  16*  I7.RWD/16/ , PCOPY/?  F/ 

-fCOr-YJ  I FILE 


Figure  6-3 

Activity  1 Example  Output 


6.5  TDL  Analyzer  - Activity  2 


* EXECUTE  TDL  ANALYZER 

NOTE  * 

NOTE 

EXECUTE  NREST 

LIMITS  XX,46K,-3K,XX  USE  APPROPRIATE  LI 

PRMFL  R*,R, S.TDL  RSTAR  FILE 

FILE  H*,ZIR,40R 

PRMFL  04,R,S,TDL  PARSE  TABLES 

DATA  02 , , COPY 

SELECTA  TDL  DESCRIPTION 

ENDCOPY 

NOTE  ANALYZER  OUTPUT  IS  ON  FILE  CODE  06 

FILE  07,X1R 

FILE  09,X2S 

PRMFL  I 1 » W , R , TDL  DATA  BASE  FILE 

PRMFL  12,R,S.ADBMS  TABLE  FILE  FOR  TDL  TA1 

FILE  13, NULL 

FILE  14, NULL 

PRMFL  TR,R,R, TRANSLATOR  LIBRARY 
IF  *8. IP  IF  TDL  ERRORS  THEN 


FI 1 code 


Description 

A required  fllecode  so  an  entry  can 
be  made  In  PAT. 

1DL  Analyzer  R*  file  from  the 
SYSGEN  tape. 

The  TDL  parsing  tables  from  the 
SYSGEN  tape. 

The  TDL  description  (In  BCD). 

TDL  Analyzer  output. 

A scratch  copy  of  the  SOURCE  SDDL 
tables. 

A scratch  copy  of  the  target  SDDL 
tables. 

Null  files  (for  dump  I/O). 

Random  library  of  Data  Translator 
object  routines  from  the  SYSGEN  tape 


Figure  6-4  shows  a sample  of  the  TOL  Analyzer  output.  TDL  Analyzer 
error  messages  are  printed  on  I/O  unit  06.  Due  to  the  parsing  algorithm 
most  error  messages  appear  two  lines  below  the  actual  error.  Thus,  the 
user  should  examine  the  two  lines  which  precede  an  error  message  for  the 
occurrence  of  the  error.  The  error  messages  are  discussed  In  Appendix  B 
Certain  errors  cause  the  TDL  Analyzer  to  enter  error  recovery  mode. 

When  this  occurs,  the  TDL  Analyzer  Is  attempting  to  continue  processing 
by  skipping  any  Input  lines  that  have  been  rendered  Invalid  due  to  a 
previous  error.  The  TDL  Analyzer  prints  error  messages  Indicating  the 
points  where  the  error  recovery  procedure  was  Invoked  and  terminated. 

Any  Intervening  Input  lines  were  not  processed  in  any  way. 

Discussion 

Activity  two  executes  the  TOL  Analyzer.  The  user  should  place 
appropriate  file  names  in  the  JCL  as  Indicated.  The  user  should  use  11ml 
appropriate  for  the  given  job  In  line  1200.  Most  TDL  Analyzer  executions 
require  less  than  0.1  hours  of  CPU  time. 


6.6  TDL  Analyzer  - Activity  3 


1360 

1370 

1380 

1390 

1400 

1410 

1420 

1430 

1440 

1450 

1460 


POST  PROCESS  I - SYSACC  BUILDER 


Filecode 


Description 

Post-process  J R*  from  SYSGEN  tape. 
TDL  tables. 

Scratch  copy  of  target  SDDL  tables. 
Translator  library  from  SYSGEN  tape 
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PAGE 


DATA 

1 

2 

3 

4 

5 

0 
7 

h 

y 
10 
1 1 

1 ? 

13 

14 

! 5 
1 6 
17 
It! 

19 

20 
21 
22 
23 
2* 

2 b 
2o 
27 
2b 

29 

30 

3 I 
3* 
33 
3* 
3b 
3b 
37 
3b 
39 
&C 

4 I 

42 

43 

44 
4b 
46 
4 / 
4b 
49 
bC 


BASE  INITIALIZED  WITH  7 PAGES. 

>/★  NHw  rR5Z  TO  PREZ  P*RTS  STATES  */ 

>/*  $U  */ 

>TARGET  RECORD  CITIES 

> TDLAP  CITI 

> SOURCE  RECORD  STATES- IN-ON  ION  ACCESS  VIA  CALC- STATES- IN-UN  ION 

> SOtiRCE  RECORD  CITIES  ACCESS  VIA  HA>S-L  ARCH-CITIES 

> ACTUAL  DATA  IN  ORDER 

> SET  SIGNIFICANT  DATA  BY  NAVE 


>TAPGET  RECORD  OCCUP-MARR 

> TDLAP  OCCU 

> SOURCE  RECORD  PRESIDENT  ACCECS  VIA  CALC-PRE^IDENT 

> FIRST-NAVE  ASSIGN  TO  PPE^-S-FN  AME-<PRES-INFO> 

> I NIT  ASSIGN  TO  PRES-S-MnAmE<PPES-INFO> 

> LAST-NAME  ASSIGN  TO  PPES-S-LNAME<PRES-INF0> 

> SOURCE  RECORD  OCCUPATION  ACCESS  VIA  HADtOCCUPATION 

> TITLE-OF-JOR  ASSIGN  TO  TITLE-OF-JOP 

> SOURCE  RECORD  MARfft I ‘GE-DATA  ACCESS  VIA 

> MAORI  AGE- 1 NFO  FRO*'  PRESIDENT 

> rtIVES-NAME  ASSIGN  TO  WIVES-NAMR 

> MONTH-MARRIED  ASSIGN  TO  VONTH-ua PRIFD 

> DAY-MARRIED  ASSIGN  TO  DAY-maORIED 

> Y = A R - a f I ED  XSSI  GN ' TO  “ Y E A R - m A’RRTE  D 

> NUMHER-OF-CHILDREN  assign  to  HU*,a e R-O F -CM I ldr EN 
>TAHGHT  RECORD  PRESIDENT-? 

> TDLAp  PRES 

> SOURCE  RECORD  PRESIDENT  ACCESS  VIA  CALC-PPE.SIDENT 

> SET  SIGNIFICANT  DATA  RY  NAME 

> FIRST -nA»'E  ASSIGN  TO  PRES-S-FNA*'E 

> IN  IT  ARSIGim  TO  PRES-S-»'NAME 

> LAST-NAME  ASSIGN  TO  PPES-S-LN AMP 
>TARGET  RECORD  STATE S-S 

> TDLAP  ST AT 

> SOURCE  RECORD  STATES- IN-UN  ION  ACCESS  VI  A CAI.C-STaTES-IN-UNION 

> STATE-NAMP  ASSIGN  to  state-name 

> YEAR -ADMITTED  ASSIGN  TO  YEAR-AD‘'ITTED 

> CAPITAL  ASSIGN  TO  CAPITAL 

> APEA-SO-MI  assign  TO  AREA-SO-MI 

> area-rank  assign  to  area-rank 

> POPULATION  ASSIGN  TO  POPULATION 

> r'OP— °ANK  ASSIGN  TO  POP-PANK 

> ELECTORAL-VOTES  ASSIGN  TO  ELECTOR aL -VOTES 

> SOURCE  RECORD  STATES- ADMITTED  ACCESS  VIA  AD« ITTED-DUR ING 

> ACCEPT  IF  NULL 

> SOURCE  RECORD  ADMINISTRATION  ACCESc  VIA 

> ADMITTED-STATES 

> ACCEPT  IF  NULL 

> ADMINISTRATION-NUMBER  ASSIGN  TO 

> ADMITTED-PY-ADMIN 

> NULL  VALUE  » ' ' 

> EOF 

Figure  6-4 

Activity  2 Example  Output 
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analyzer  statistics 


Initialization  time  * o.65  seconds 

PROCESSING  TIME  ■ 11.43  SECONDS 

JUMPING  TIME  = 0.04  SECONDS 

iOTAL  TIME  * 12.11  SECONDS 

50  CARDS  WERE  PROCESSED 
PROCESSING  RATE*  262  CARDS/MINUTE 

0 ERROR! $)  AND  0 #ARNING!S)  WERE  DETECTFD 


Figure  6-4  (cont.) 


Figure  6-5  shows  the  output  generated  by  this  activity. 

Discussion 

The  user  should  supply  appropriate  file  names  and  limits  as  Indicated 
Most  executions  of  this  activity  require  less  than  0.1  hours  of  CPU  time. 


6.7  TOL  Analyzer  - Activity  4 


II 
0 


NOTE  ♦ ***** +++*+++  +++++* ******** ★★★★★ *******  ****** 

NOTE  * * 

NOTE  * POST  PROCESS  II  - COMPATIBILITY  BUILDER  * 

NOTE  * * 

NOTE  »**★**»★»***»★»»»>* »»*»»»»★★★★★★★★★★★★*★★»★★» 

EXECUTE  NREST 

LIMITS  XX,52K,-3K,XX  USE  APPROPRIATE  LIMITS 

PRMFL  R*,R,  S«COMPATIBILITY  RSTAR  FILE 

PRMFL  07,W,R,TDL  DATA  BASE  FILE 

FILE  08.X2S 

PRMFL  TR,R,R, TRANSLATOR  LIBRARY 


Fllecode 


Post-process  IIR*  from  SYSGEN  tape 
TDL  table. 

Scratch  copy  of  target  SDDL  tables. 
Translator  library  from  SYSGEN  tape 


Figure  6-6  shows  the  output  generated  by  this  activity 


Discussion 

The  user  should  supply  appropriate  file  names  and  limits  as  Indicated 
Most  executions  of  this  activity  require  less  than  0.1  hours  of  CPU  time. 
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6.8  TDL  Analyzer  - Actlvli 


1580 

1590 

1600 

1610 

1620 

1630 

1640 

1650 

1660 

1670 

1680 

1690 


NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

IF 

EXECUTE 

LIMITS 

PRMFL  • 

PRMFL 

NOTE 

PRMFL 


******  .*  0 * * **  **+*+*++++++ 

* m 

* TDL  TABLE  BUMPER  * 

* * 


1 9 , END JOB  SKIP  DUMP  IF  NOT  REQUESTED 

NREST 

XX,25K,-3K,XX  USE  APPROPRIATE  LIMITS 
R*,R,S,TDL  DUMPER  RSTAR  FILE 
02«R<*R«TDL  DATA  .BASE  FILE 
DUMP  OUTPUT  IS  ON  FILE  CODE  06 
TR*R,R, TRANSLATOR  LIBRARY 


Fllecode 

LUD 

Description 

R* 

mm  mm  mm 

R*  file  for  TDL  table. 

Dumper  from  SYSGEN  tape. 

02 

tmmm 

TDL  tables. 

06 

»mmmm 

TOL  dump  output. 

TR 

— 

Translator  library  from  SYSGEN  tape. 

Example  of  Output 

Figure  6-5  shows  an  example  of  part  of  the  TDL  dump  output.  The  TDL 
user  dump  output  provides  the  user  with  a description  of  the  TDL  tables 
that  were  produced.  The  dump  Is  arranged  by  target  records.  It  Includes 
many  Items  of  Information  with  which  the  Inexperienced  or  casual  user 
should  not  be  concerned.  The  TDL  user  dump  Is  primarily  provided  for 
those  users  whose  restructuring  needs  call  for  unorthodox  or  complicated 
TDL  descriptions.  The  casual  user  may,  however,  find  It  a useful  device 
for  verifying  that  the  TDL  description  Is  correct. 

Discussion 

The  user  should  supply  the  appropriate  file  names  and  limits  as 
Indicated.  Most  executions  of  this  activity  require  less  than  0.1  hours 
of  CPU  time. 
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7.0  THE  READER  MODULE 

The  fourth  step  In  the  Data  Translation  process  is  running  the  Reader. 
The  Reader  Is  the  first  module  to  work  with  the  user's  data.  It  converts 
the  user's  WWDMS  sequential,  ISP  or  IDS  database  to  one  AD6MS  database 
called  the  source  RIF.  The  source  RIF  (SRIF)  Is  logically  equivalent  to 
the  source  database(s).  The  Reader  Is  driven  by  information  stored  in  the 
source  SDDL  tables.  Before  the  Reader  can  be  run  the  following  steps  must 
be  completed: 

1.  The  source  SDDL  tables  must  be  successfully  created. 

2.  The  source  database(s)  should  be  available.  MD  sections 
for  all  IDS  databases  should  be  available. 

3.  All  necessary  files  (see  Section  7.4)  should  be  created. 


7.1  Reader  Submodules 

The  Version  IIA  Release  2 Data  Translator  has  three  Reader  modules: 
one  each  for  WWDMS  sequential,  ISP  and  IDS  databases.  Each  Reader  per- 
forms the  same  function,  that  Is,  produces  the  source  RIF,  but  due  to 
the  differences  of  each  of  the  file  systems  the  Readers  consist  of  different 
submodules  to  improve  operating  efficiency.  The  architecture  of  each 
Reader  is  shown  in  Figure  7-1,  7-2,  and  7-3.  Figure  7-4  shows  the  Reader 
configuration  for  one  IDS,  one  ISP  and  two  WWDMS  sequential  databases. 

Although  Figure  7-4  is  probably  not  a typical  example,  it  shows  the  use  of 
all  three  Readers  to  create  one  SRIF. 

The  Reader  submodules  of  which  the  user  should  be  aware  and  should 
understand  are  the  following: 

1.  Accessor  (IDS,  ISP,  sequential)  - the  Accessor  retrieves  logical 

records  from  the  database.  The  IDS  Accessor  is  a COBOL-IDS 
program  which  only  reads  pages  and  returns  information  describing 
each  logical  record.  Note  that  the  IDS  Accessor  must  be  com- 
piled with  the  MD  section  for  the  database  before  the  IDS 
Reader  can  be  run. 

2.  Populator  (Network,  Hierarchical)  - the  Populator  controls  the 

linking  of  sets  in  the  SRIF.  It  duplicates  the  logical 
relationships  that  exist  In  the  source  database(s)  in  the 
SRIF.  The  network  Populator  uses  an  internal  database  called 
the  Deferred  Reference  Table  (DRT).  The  DRT  contains  infor- 
mation about  sets  in  the  SRIF. 

3.  Reader  Control  - the  Reader  Control  submodule  is  essentially  the 

same  for  each  Reader.  It  performs  initialization  and  wrapup 
steps,  moves  data  to  the  SRIF,  links  SYSTEM-owned  sets,  and 
links  match-key  relations. 

7.2  Reader  Processing  Flow 

Each  Reader  uses  the  same  type  of  algorithm,  only  capabilities  differ. 

The  first  step  of  the  Reader  algorithm  Is  Initialization.  During  Initiali- 
zation the  DDL  Writer  module  Is  executed.  It  writes  the  ADBMS  DDL  for  the 
SRIF  using  Information  In  the  source  SDDL  tables.  Then,  If  this  Is  the 
first  Reader  run,  the  SRIF  Is  Initialized  and  (If  IDS  Reader)  the  DRT 
database  Is  initialized. 
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Figure  7-2 
ISP  Reader 


Figure  7-4 
Reader  Example 


The  second  step  Is  the  major  section  of  the  Reader.  Each  record  In  the 
source  database  Is  read  and  moved  to  SRIF.  Data  conversion  Is  performed  If 
necessary.  The  Populator  then  links  the  record  In  the  SRIF  Into  all  of  Its 
sets.  This  process  continues  until  either  the  database  has  been  entirely 
read  or  a user-specified  number  of  records  has  been  read.  The  last  step, 
wrepup,  Involves  duping  a sample  of  the  SRIF,  dunplng  the  DRT  (If  IDS 
Reader)  and  linking  natch-key  relations  (If  this  Is  the  last  source  database) 
Figures  7-S,  7-6,  and  7-7  show  the  processing  steps  and  sequencing  for  each 
Reader. 


7.2.1  Restrictions  and  Warnings 

The  Reader  has  the  following  restrictions  and  the  user  should  also 
note  each  warning: 

1.  No  Itens  or  records  longer  than  640  words. 

2.  Contalned-ln-repeatlng  groups  (CIRGs)  are  not  allowed  In  CIR6s. 
That  Is,  only  one-dluenslonal  arrays  or  vectors  are  allowed. 

3.  User-defined  pointer  fields  (phanton  pointers,  pointer  arrays) 

must  be  fullword  Integers.  . ^ L . 

4.  Only  IS  detail  record  typos  are  allowed  for  each  IDS  chain  type. 

5.  Mien  double  word  Integers  are  converted  Internally  to  single-word 
Integers,  If  overflow  occurs,  the  Item  will  be  set  to  zero. 


7.3  Reader  JCL 

This  section  explains  the  JCL  required  to  run  each  Reader,  and  user 
actions  which  Must  be  performed. 


7.3.1  IDS  foafler  JCL. 

The  IDS  Reader  consists  of  three  activities.  The  first  copies  the 
source  SDOL  tables  and  an  Internal  database  used  by  the  DDL  Writer  to 
tenorary  files.  The  second  activity  Is  the  ampliation  of  the  IOS  Accessor 
The  IOS  Accesspr  is  supplied  as  two  source  decks  Into  which  the  user's  ND 
section  Must  be  Inserted.  The  third  activity  Is  the  execution  of  the  IDS 
Reader.  Figure  7-8  provides  an  example  of  the  IDS  Reader  JCL. 

The  IOS  Reader  can  be  set  to  read  only  a fixed  nwber  of  records^vla 
a run-time  parameter.  Therefore,  a source  database  can  be  processed  Incre- 
mentally In  specified  pieces  with  Interruptions  In  the  process.  Many  IDS 
databases  can  also  Jbe  combined  Into  one  SRIF. 


Figure  7-5 

IDS  Reader  Processing  Flow 
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Figure  7-7 

Sequential  Reader  Processing  Flow 
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Figure  7*9 
ISP  Reader  JCl 


The  ISP  Reader  consists  of  two  activities.  The  first  activity  copies 
the  SOOt  tables  and  an  Internal  database  used  by  the  ML  Writer  to  temporary 
file*,  tha  sacond  activity  is  tha  axacutlon  of  the  ISP  Reader.  Figure  7-9 
Indicates  the  JCL  required  to  run  the  ISP  Reader. 


Figure  7-10 
Sequential  Reader  JCL 


The  Sequential  Reader  consists  of  two  activities.  The  first  activity 
copies  the  SDOL  tables  and  an  Internal  database  used  by  the  DDL  Writer  to 
temporary  files.  The  second  activity  executes  the  Sequential  Reader.  Figure  7-10 
Indicates  the  JCL  for  the  Sequential  Reader. 

7.4  Files  and  Reports 

An  explanation  of  the  files  and  output  for  the  IDS  Reader  Is  given  In 
Section  7.5.  Sections  7.6  and  7.7  explain  the  files  and  output  for  the  ISP  / 

and  sequential  Readers. 
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7.5  IDS  Reader  Files  and  Reports 
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Activity  1 


7.5.1  Activity  1 

The  first  activity  of  the  IDS  Reader  copies  the  source  SDDL  tables 
and  an  internal  database  used  by  the  DDL  Writer  to  temporary  files. 

Line  80  (in  Figure  7-11)  should  refer  to  the  file  ontaining  the  source 
SDDL  tables.  Line  100  should  refer  to  the  DDL  writer's  work  database  that 
was  brought  off  the  system  generation  tape  (see  Appendix  6).  The  user  should 
check  report  code  53  to  be  sure  the  first  activity  terminated  normally. 


7.5.2  Activity 
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Figure  7-12 
Activity  2 

The  second  activity  compiles  the  IDS  Accessor.  The  two  sections  of 
Accessor  source  code  should  be  brought  off  the  system  generation  tape  (see 
Appendix  G)  and  saved  In  permanent  files.  Lines  160  and  180  (in  Figure 
7-12)  should  refer  to  those  files.  The  MD  section  for  the  database  to  be 
read  should  be  Inserted  in  line  170.  The  MD  section  should  begin  with  MD 
FILE  IS... not  IDS-SECTION.  The  following  words  should  not  be  included  in 
the  user's  MD  section: 


ACC-C-ADDR 

ACC-CHECK-FOR-PAGE-HEADER 

ACC-DEFINE-SYMBOLS 

ACC-DELETE-SWITCH 

ACC-END-DB 

ACC-EOF 


ACC-ERROR-VALUE 
ACC-FIRST-TIME 
ACC- I ERROR 
ACC-LEN 
ACC-OPEN- DB 
ACC-REC-TYP 


ACC-TOTAL-REC 

ACC-TOTAL-RECORDS 

ACC-TOTAL-STRING 

ACC-TR 

ACC-W-ADOR 


ACC-REF-COD 

ACC-RETRIEVE-RECORD 

ACC-RETURN-PARA 

ACC-SET-UP-REF-CODES 


The  MD  section,  not  the  Accessor  code,  should  be  changed  If  any  of  the  above 
words  appear  In  the  user's  MD  section.  Report  code  74  should  be  checked 
for  IDS  or  COBOL  compilation  errors.  Errors  due  to  name  conflict  should 
be  corrected  and  the  Reader  can  be  run. 
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Figure  7-13 
Activity  3 

The  following  lines  should  be  set  In  Figure  7-13  as  follows: 


Line 

230 

250 


Contents 

This  should  be  the  IDS  Reader  R*  file  to  be 
used.  It  should  be  saved  In  a permanent  file 
created  from  the  system  generation  tape  (Appendix  G). 

The  core  limit  should  be  set  to  the  size  given  for 
the  IDS  Reader  In  Appendix G.  The  CPU  limit  should 
be  set  so  that  the  Reader  can  finish  In  the  allotted 
time.  Assume  that  the  Reader  can  process  approximately 
6000  IDS  records  per  CPU  hour. 
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The  Translation  Library  Is  a library  of  low-level 
routines  essential  to  the  Reader.  It  can  be  found 
on  the  system  generation  tape  (Appendix  G). 

The  user  should  create  a random  file  which  Is 
about  twenty-five  percent  the  size  of  the  source 
IDS  database  to  be  used  as  the  DRT  database.  That 
file  should  be  referenced  here. 

The  DRT  ADBMS  DBTF  should  be  copied  off  the  system 
generation  tape  to  a permanent  file  (1  11 Ink, 
sequential). 

The  IDS  Reader's  Internal  file  should  be  copied  off 
the  system  generation  tape  to  a permanent  file 
(1  lllnk,  sequential). 

The  run-time  parameters  should  be  set  here.  There 
are  five  run-time  parameters: 

1.  The  word  "FIRST"  should  be  Included  on  this 
line  If  and  only  if  this  Is  the  first  time 
the  Reader  has  accessed  the  source  database. 

2.  The  word  "LAST"  should  be  Included  on  this 
line  If  and  only  If  this  Is  the  last  run 

on  the  source  database.  Note  that  If  there 
Is  only  one  run  of  the  Reader  "FIRST"  and 
"LAST"  both  should  be  used. 

3.  The  word  "DEBUG"  should  be  Included  on  this 
line  If  and  only  If  a list  of  IDS  reference 
codes  and  corresponding  ADBMS  keys  Is  desired. 

For  each  set  Instance  In  each  record  Instance, 
the  IDS  reference  codes  and  set  type  will  be 
printed.  Note  that  this  could  potentially  pro- 
duce an  extremely  large  amount  of  output. 

4.  The  name  of  the  database  must  be  Included  on 
this  line  In  the  form: 

NAME«database-name 

where  database-name  Is  the  name  of  the  database 
and  Its  first  character  Immediately  follows  the 
equals  sign. 

5.  The  number  of  records  to  be  retrieved  from  the 
IDS  database  should  be  Included  here  In  the 
form: 

RECORDS-n  or 
RECORDS-ALL 

where  the  first  n records  will  be  retrieved  or 
ALL  records  are  to  be  retrieved.  Note  that  the 
IDS  Reeder  can  read  a database  of  100,000  records 
by  running  the  Reader  ten  times  with  RECORDS 
•10000. 

The  source  RIF  should  be  a random,  permanent  file. 

It  should  be  about  twice  the  size  of  all  source 
databases. 


The  source  IDS  database  should  have  fllecode 
XI.  Subfiles  should  have  filecodes  X2,  X3,  etc 


7.5.4  IDS  Reader  Output  and  DRT  Dump 

All  Reader  output  which  is  of  any  value  to  the  user  can  be  found  in 
report  code  06.  An  example  of  the  first  page  of  output  is  shown  in  Figure 
7-14.  After  the  page  header,  the  run-time  parameters  are  printed  as  they 
appeared  in  the  run-time  parameter  file.  The  next  four  lines  are  Initiali- 
zation messages  from  the  ADBMS  system.  The  first  Initialization  message 
corresponds  to  the  SRIF  and  the  second  line  corresponds  to  the  DRT  database. 
(Note  that  a page  Is  1024  words).  If  there  were  no  errors  during  the  Reader 
execution,  the  number  of  IDS  records  retrieved  and  the  number  of  logically 
deleted  IDS  records  which  were  physically  deleted  in  the  SRIF  will  be  printed 
If  there  were  errors  In  the  Reader  execution,  error  messages  will  be  written 
after  the  database  Initialization  message. 

Beginning  on  the  second  page  of  output  will  be  the  final  dump  of  the 
DRT  database.  The  DRT  dump  contains  Information  concerning  every  chain-type 
relation  in  the  source  IDS  database(s).  For  each  set  In  the  SRIF  there 
will  be  a line  of  output  with  the  name  of  the  set  (RELATION),  the  set  type 
(TYPE),  the  master  and  detail  records  (PARENT,  DEPENDENT),  the  sibling  set 
type  (SIBLING),  and  the  displacement  and  length  of  the  pointer  fields  In 
the  master  and  detail  (OWNDIS,  OWNLEN,  MEMDIS,  MEMLEN).  The  set  type  (TYPE) 
can  be  either  an  IDS  chain  (IDSCHN)  or  a user's  phantom  pointer  (PHNCHN). 

The  sibling  set  type  (SIBLING)  can  be  disregarded  by  the  user.  The  length 
and  displacement  of  the  pointer  fields  should  be  checked  for  correctness. 

Since  the  DRT  dump  can  take  on  many  different  forms  the  following 
general  tips  should  help  the  user  determine  whether  the  Reader  ran  correctly. 
These  tips  apply  only  when  the  Reader  Is  run  for  the  LAST  time.  For  all 
other  runs,  the  DRT  dump  can  be  Ignored. 

1.  For  IDSCHN- type  relations,  only  the  line  of  output  with  the 
relation  name,  etc.,  should  appear.  (See  Figure  7-15).  If  the 
relation  header  line  is  followed  by  a line  with  FIRST,  NEXT, 

PARENT,  etc.,  some  sort  of  error  has  occurred.  The  problem  could 
be  In  the  source  database(s)  or  the  Reader.  Data  Translation 
personnel  should  be  contacted  to  pinpoint  the  error. 

2.  For  PHNCHN- type  relations,  the  line  of  output  with  the  relation 

name,  etc.,  should  be  followed  by  FIRST,  NEXT,  PARENT,  etc..  If 
there  were  any  Instances  of  that  relation  In  the  source  database. 
Figure  7-16  shows  an  example  of  this  type  of  output.  Under  the  word 
PARTYP,  REAL  should  be  the  only  word  which  appears.  If  the  word 
SURG  Is  present,  an  error  has  occurred  and  Data  Translation 
personnel  should  be  contacted.  Under  IDSKEY  Is  the  IDS  reference 
code  of  the  owner  of  the  set  Instance  and  under  NUMMEM  Is  the 

number  of  members  of  the  set  Instance.  A few  of  the  set  Instances 

should  be  checked  In  the  source  database  to  be  sure  they  are  correct 

3.  If  any  IDS  reference  code  field  (FIRST,  NEXT,  IDSKEY)  Is  not  a 

valid  IDS  reference  code  (maybe  It  Is  blanks  or  other  characters),  the 
user  should  check  the  OWNDIS,  OWNLEN,  MEMOIS  and  MEMLEN  for  the 
correct  values.  If  an  Incorrect  value  appears,  the  IDS  MD  section 
should  be  corrected,  the  SOOL  tables  should  be  recreated  and  the 
Reader  should  be  rerun. 
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REAL  000000003603 
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Figure  7-16 
DRT  Dump 
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KEY-000002000077  IDS  REF-OOOOOOOOOIOI  PRESID 

PRESID  P-A  OOOOOOOOOIOI  000000003701  1 0 

PRESZD  P-E  000000000101  000000001301  1 0 

PRESID  P-PCL  000000000101  000000005312  1 0 

p»r?5lID  s-P  000000000101  000000003203  2 0 

K.  '*02000305  IDS  REF-000000000102  PRESID 

* 000000000102  000000003714  1 0 

-I;  000000000102  000000001003  1 0 

. 000000000102  000000005345  1 0 

(v>rs.  v *wp  000000000102  000000003604  2 0 

KEY-000002000501  IDS  REF-000000000103  PRESID 

PRESID  P-A  000000000103  000000004102  1 0 

PRESID  P-E  000000000103  000000000103  1 0 

PRESID  P-PCL  000000000103  000000005372  1 0 

PRESID  S-P  000000000103 : 000000001703  2 0 

KEY-000002000675  IDS  REF-000000000104  PRESID 

PRESID  P-A  000000000104  000000004204  1 0 

PRESID  P-E  000000000104  000000001010  1 0 

PRESID  P-PCL  000000000104  000000005426  1 0 

PRESID  S-P  000000000104  000000002603  2 0 

KEY-000002001057  IDS  REF-000000000105  PRESID 

PRESID  P-A  000000000105  000000004205  1 0 

PRESID  P-E  000000000105  000000001207  1 0 

PRESID  P-PCL  000000000105  000000005435  1 0 

PRESID  S-P  000000000105  000000000205  2 0 

KEY-000002001241  IDS  REF-000000000106  PRESID 

PRESID  P-A  000000000106  000000004213  1 0 

PRESID  P-E  000000000106  000000001013  1 0 

PRESID  P-PCL  000000000106  000000005502  1 0 

PRESID  S-P  000000000106  000000001604  2 0 

KEY-000002001423  IDS  REF-000000000201  PRESID 

PRESID  P-A  000000000201  000000003707  1 0 

PRESID  P-E  000000000201  000000001001  1 0 

PRESID  P-PCL  000000000201  000000005336  1 0 

PRESID  8-P  000000000201  000000003504  2 0 

KEY-000002001631  IDS  REF-000000000202  PRESID 

PRESID  P-A  000000000202  000000003711  1 0 

PRESID  P-E  000000000202  000000001002  1 0 

PRESID  P-PCL  000000000202  000000005340  1 0 

PRESID  8-P  000000000202  000000003103  2 0 

KEY-000003000045  IDS  REF-000000000203  PRESID 

PRESID  P-A  000000000203  000000004014  1 0 

PRESID  P-E  000000000203  000000001205  1 0 

PRESID  P-PCL  000000000203  000000005367  1 0 

PRESID  S-P  000000000203  000000000603  2 0 
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Figure  7-18 
DEBU6  Output 


7.5.5  Source  RIF  Dump 

After  the  ORT  dump,  a small  portion  of  the  SRIF  Is  dumped.  For  each 
SYSTEM-owned  set  In  the  SRIF,  the  first  and  last  member  of  the  set  Is  dumped 
An  example  of  this  output  Is  shown  In  Figure  7-17.  After  the  page  header, 
the  name  of  the  set  and  the  number  of  members  are  printed.  The  name  of 
the  member  record  and  the  ADBMS  key  for  that  record  Instance  are  then 
printed.  The  user  can  generally  Ignore  the  list  of  set  pointers  for  the 
record.  The  list  of  data  items  should  be  closely  checked  for  errors  such 
as  missing  data  and  data  with  unreasonable  values.  For  each  data  Item, 
the  name  of  the  field  Is  written  and  then  Its  value  Is  printed.  Character 
data  Items  are  delimited  by  asterisks  whereas  Integer  and  floating  point 
data  are  not  delimited.  If  an  error  Is  found  In  any  Item,  the  user  should 
determine  whether  the  problem  Is  In  the  IDS  database  or  the  Reader,  and 
then  correct  It.  Note  that  some  records  may  be  dumped  twice  If  they  are 
members  of  CALC  sets. 


7.5.6  Debug  Output 

When  the  user  specifies  DEBUG  as  a run-time  parameter,  additional  out- 
put will  be  written  on  report  code  06.  The  DRT  will  be  dumped  after  It 
has  been  Initialized,  and  for  each  record  Instance  In  the  source  database(s) 
the  following  output  will  be  printed: 

1.  The  IDS  reference  code  of  the  record  (IDS  REF*). 

2.  The  ADBMS  key  of  the  logically  equivalent  record  in  the  SRIF  (KEY*) 

3.  For  each  set  Instance  In  the  record,  a line  will  be  printed  with 
the  name  of  the  record,  the  name  of  the  set,  the  IDS  reference 
code  of  the  current  record,  the  IDS  reference  code  of  the  NEXT 
record  In  this  set  Instance,  a flag  (*2 If  member  In  the  set, 

■1  If  owner  of  the  set)  and  the  deletion  flag  (*1  If  logically 
deleted). 

An  example  of  the  debug  output  is  shown  In  Figure  7-18.  The  user  should 
note  that  the  DEBUG  feature  can  produce  a considerable  amount  of  output 
for  a large  database. 


7.6  ISP  Reader  Files  and  Reports 


Flaure  7-19 
Activity  1 


7.6.1  Activity  1 

The  first  activity  of  the  ISP  Reader  copies  the  source  SDOL  tables  and 
an  Internal  database  used  by  the  DDL  Writer  to  temporary  files,  line 
60  (In  Figure  7-19}  should  refer  to  the  file  containing  the  source  SDOL 
tables,  line  100  should  refer  to  the  DOL  Writer's  work  database  that  was 
brought  off  the  system  generation  tape  (see  Appendix  6).  The  user  should 
check  report  code  S3  to  be  sure  the  first  activity  terminated  normally. 


S PRMFL  R*.R.S  ,*■*■**•★***+* 

s FILE  -i*.V I R , 1 5R 

S LIMITS  ★*.**<. -5K. 50000 

s PRMFL  T9 ♦«' . R . ★*■*★*★*■*★★ 

s FILE  03.S1R.I0R 

S DATA  05 

RUN -T IMF  hAPaUSTER.S 

s REMOTE  Op 

$ FILS  07.AIR.10R 

S pPMFL  0° , /( . 0 , *+•*■+-*•*★**-* 

s FILE  1<V^2R.  10L 

s FILS  12.a3R.10L 

S FILE  13. NULL 

$ PRVFL  1 5.  °«R.  **+*++**•+* 

$ pOMFL  IF.  R.  R.  **★*■*"*•  *+*★ 

S DAT'  DC 

IFF  INDEX  F 0= I F 

I"P  ' DATA  PC* 1 5 

I Sp  RECORD  ***★★•**•*★*■ 

£ Si  ID  J OH 


OSADER  R*  FfLS 


SST  COPE  AND  CPU  LIMITS 
TRANSLATION  T I^R  AOY 
DDL NT  WORK  0° 


REPORT  OUTPUT 
SDDL  TAMfE  DAT  A*  ASF 
SOURCE  RIF 
SCRATCH  FILS 
SCRATCH  FILS 


SOURCE  ICP  OAT A 
ISP  INDEX  FILS 
ISP  DATA  CARDS 


Figure  7-20 

Activity  2 


To  run  the  ISP  Reader  the  following  lines  should  be  set  In  Figure 


Contents 

This  should  be  the  ISP  Reader  R*  file.  It  should 
be  brought  off  the  system  generation  tape  (see 
Appendix  G). 

The  core  limit  should  be  set  to  the  size  given  for 
the  ISP  R*  file  in  Appendix  G.  The  CPU  limit  should 
be  set  so  that  the  Reader  can  finish  In  the  allotted 
time.  Assume  the  Reader  can  process  approximately 
6000  records  per  hour. 


B !€!&  SM  \ 

#•' ! 1 M*«OL  '*<'  %■&$■  • 

■ R I 

if  1 c. 

^ %rf 

The  Translation  Library  Is  a library  of  low-level 
routines  essential  to  the  Reader.  It  can  be 
found  on  the  system  generation  tape  (Appendix  6). 

The  run-time  parameters  should  be  set  here. 

There  are  three  run-time  parameters. 

1.  The  word  "FIRST"  should  be  Included  on  this 
line  If  and  only  If  this  Is  the  first  time 

the  Reader  has  accessed  the  source  database(s). 

2.  The  word  "LAST"  should  be  Included  In  this  line 
If  and  only  If  this  Is  the  last  run  on  the 
source  database.  Note  that  If  there  Is  only 
one  run  of  the  Reader,  both  "FIRST"  and  "LAST" 
should  be  used. 

3.  The  name  of  database  must  be  Included  on  this 
line  In  the  form: 

NAf€«database-name 

where  database-name  Is  the  name  of  the  database 
and  Its  first  character  Immediately  follows  the 
equal  sign. 

The  source  RIF  should  be  a random  permanent  file. 

It  should  be  created  about  twice  the  size  of  all 
source  databases. 

The  source  ISP  database  should  have  fllecode  15. 

The  ISP  Index  file  should  have  fllecode  IF. 

These  ISP  data  cards  should  be  changed  only  If 
a non-standard  (320  words)  page  size  or  commercial 
collating  sequence  Is  used  In  the  ISP  database. 

The  ISP  parameters  specifying  record  length,  key 
size,  and  key  offset  should  be  set  here. 


The  output  from  the  ISP  Reader  is  on  report  code  06.  The  statistical 
report  from  the  ISP  system  Is  on  report  code  73  but  the  user  can  Ignore  that 
output.  An  example  of  the  first  page  of  output  Is  shown  In  Figure  7-21. 

After  the  page  hWder,  there  Is  a line  with  the  run-time  parameters  as  they 
were  listed  In  the  run-time  parameter  file.  The  next  three  lines  of  output 
are  Initialization  messages  from  the  AD8MS  system.  The  database  which  Is 
Initialized  Is  the  source  RIF.  If  there  were  no  errors  during  the  execution 
of  the  Reader  the  next  line  should  be  the  number  of  records  retrieved  from 
the  ISP  database.  If  there  were  errors  during  the  .run,  the  error  messages 
will  be  printed  after  the  Initialization  message. 

The  other  output  from  the  ISP  Reader  Is  a dump  of  a few  records  In  the 
source  RIF.  Since  this  output  Is  the  same  In  the  IDS  Reader,  the  user  should 
refer  to  Section  7.5.5  and  Figure  7-17  for  an  explanation  and  sample  of  that 
output. 


IDENT 
NOTE 
NOTE 
NOTE 
UTILITY 
FUTIL  A1 .A2.RCOPY/1F/ 
FUTIL  Bl .R2.RCOPY/IF/ 
PRMFL  A I , R, R.  **★★★**★■ 
FILE  A2, A I S. 10R 

PRMFL  B 1 »N , R. ★★*★★★★★ 
FILE  B2.B1S.10R 


< ■ UTILITY  COPY 


SDDL  TABLE  DATA0  * SR 


DDL  NT  WORK  DR 


Figure  7-22 
Activity  1 


7.7.1  Activity  1 

The  first  activity  of  the  sequential  Reader  copies  the  source  SOX 
tables  and  an  Internal  database  used  by  the  DDL  Writer  to  temporary  files. 
Line  80  (in  Figure  7-22)  should  refer  to  the  file  containing  the  source  SDDL 
tables.  Line  100  should  refer  to  the  DX  Writer's  work  database  that  was 
brought  off  the  system  generation  tape  (see  Appendix  6).  The  user  should 
check  report  code  53  to  be  sure  the  first  activity  terminated  normally. 


7.7.2  Activity  2 


NOTE 
NOTE 
NOTE 
EXECUTE 
PRMFL 
FILE 
LIMITS 
PRMFL 
FILE 
DATA  05 

RUN-TIME  PARAMETERS 
REMOTE  06 

FILS  07. A I R, I OR 

PRMFL  09,  W.  R , ******  irk  irk 

FILE  I0.R2R.10L 

FILE  I2.R3R.10L 

FILE  13. NULL 

PRMFL  1 5, P. S, ********** 
END-JOB 


< EXECUTE  THE  READER 


READER  R*  FILE 


SET  COPE  AND  CP'J  LIMITS 
TRANSLATION  LIBRARY 
DDLWT  WORK  DR 


REPORT  OUTPUT 
°DDL  TARLE  DATABASE 
SOURCE  RIF 
SCRATCH  FILE 
SCRATCH  FILE 


SOURCE  SEO.  DATABASE 


Figure  7-23 
Activity  2 


To  run  the  sequential  Reader  the  following  lines  should  be  changed 
In  Figure- 7-23: 

Line  Contents 

160  This  should  be  the  sequential  Reader  R*  file.  It 

should  be  brought  off  the  system  generation  tape 
(see  Appendix  6). 

180  The  core  limit  should  be  set  to  the  size  given  for 

the  sequential  Reader  In  Appendix  6.  The  CPU  limit 
should  be  set  so  that  the  Reader  can  finish  In  the 
allotted  time.  Assume  the  Reader  can  process 
approximately  6000  records  per  hour. 

190  The  Translation  Library  Is  a library  of  low-level 

routines  essential  to  the  Reader.  It  should  be 
brought  off  the  system  generation  tape  (see 
Appendix  G). 

220  The  run-time  parameters  should  be  set  here.  There 

are  three  run-time  parameters: 

1.  The  word  "FIRST"  should  be  Included  on  this 
line  If  and  only  If  this  Is  the  first  time 

the  Reader  has  accessed  the  source  database(s). 

2.  The  word  "LAST"  should  be  Included  In  this 
line  if  and  only  If  this  Is  the  last  run  on 

the  source  database.  Note  that  If  there  Is  only 
one  run  of  the  Reader,  both  "FIRST"  and  "LAST" 
should  be  used. 

3.  The  name  of  the  database  must  be  Included  on 
this  line  In  the  form: 

NAME*database-name 

where  database-name  Is  the  name  of  the  database 
and  Its  first  character  Immediately  follows  the 
equal  sign. 

250  The  source  RIF  should  be  a random  permanent  file. 

It  should  be  created  about  twice  the  size  of  all 
source  databases. 

290  The  source  sequential  database  should  have  file 

code  15.  If  the  database  Is  on  a tape,  the  LUO 
used  for  the  tape  drive  should  not  conflict  with 
any  other  LUOs  used  by  the  Reader. 


7.7.3 


luentlal  Reader  Output 


The  output  from  the  sequential  Reader  Is  on  report  code  06.  An  example 
of  the  first  page  of  output  Is  shown  In  Figure  7-24.  After  the  page  header, 
there  Is  a line  with  the  run-time  parameters  as  they  appeared  In  the  run-time 
parameter  file.  The  next  three  lines  of  output  are  from  the  ADBMS  system 
during  the  SRIF  Initialization  process.  If  there  were  no  errors  during  the 
execution  of  the  Reader,  the  next  line  should  be  the  number  of  records  retrieved 


mmrnssM 


from  the  sequential  database.  If  there  were  errors  during  the  run,  the 
error  Messages  will  be  printed  after  the  SRIF  Initialization  message. 

The  other  output  from  the  sequential  Reader  Is  a dump  of  a few  records 
In  the  source  RIF.  Since  this  output  Is  the  same  as  In  the  IDS  Reader, 
the  user  should  refer  to  Section  7.S.5  and  Figure  7*17  for  an  explanation 


and  sample  of  that  output 


8.0  RUNNING  THE  RESTRUCTURER 

The  Restructure  Is  the  second  of  the  three  major  modules  of  the 
Data  Translator.  After  the  Reader  has  produced  an  ADBMS  database  that 
Is  logically  equivalent  to  the  original  IDS  source  database,  the 
Restructure*  must  be  run  to  perform  the  logical  transformations  speci- 
fied by  the  TDL.  The  output  Is  another  ADBMS  database  in  relational 
(rather  than  network)  form.  This  database  Is  then  used  by  the  Writer 
to  produce  a logically  equivalent  network  IDS  database. 

The  following  checklist  Indicates  the  steps  of  the  translation 
process  which  should  be  completed  before  attempting  to  run  the  Restructure: 

1.  The  user  must  generate  SDOL  tables  for  both  the  source  and 
target  databases'. 

2.  The  Reader  must  be  run  to  produce  a source  RIF  database. 

3.  A TDL  description  of  the  desired  translation  must  be  written 
and  analyzed  to  generate  TDL  tables. 

4.  A random  file  must  be  created  to  hold  the  target  RIF  database. 

Its  size  must  be  a multiple  of  12  lllnks  (see  Section  8.4.1). 

When  the  above  steps  have  been  completed,  the  user  Is  ready  to  run  the 
Restructure. 


ents  of  the  Restructure 


8.1  Major 

Figure  8-1  shows  the  major  components  of  the  Restructure.  The 
arrows  Indicate  the  direction  of  Information  flow  among  the  various 
components.  The  following  Is  a brief  explanation  of  each: 

USER-INPUT  DIRECTIVES:  User-supplied  statements  that  control  varloi 


SOURCE  RIF  DATABASE: 


"NAMES"  TDL  TABLES: 


"POINTERS"  TDL  TABLES: 


User-supplied  statements  that  control  various 
aspects  of  the  Restructure  run  (e.g. , whether 
or  not  to  Initialize  the  target  RIF  database). 

An  ADBMS  database,  output  by  the  Reader, 
which  Is  logically  equivalent  to  the  user's 
original  IDS  database. 

An  A08MS  database,  output  by  the  TDL  Analyzer, 
which  contains  all  the  translation  Information 
specified  by  the  user's  TDL  description. 

A copy  of  the  "NAMES"  TDL  tables  In  which  all 
ADBMS  names  (e.g.,  record  type  names)  have  been 
replaced  with  symbolic  pointers.  The  necessary 
processing  Is  performed  by  the  Restructurer 
prior  to  the  actual  restructuring  of  the  database. 
This  second  copy  of  the  TDL  tables  Is  used  to 
avoid  having  to  Interpret  the  same  ADBMS  literals 
over  and  over  again  each  time  a target  record  Is 
created  or  a source  record  accessed.  This 
saves  considerable  processing  time  during  the 
Restructure  run. 


TARGET 


TABLES 


INITIALIZER 


TABLES 


USER-INPUT 

DIRECTIVES 


RESTRUCTURER 


SOURCE 


TARGET 


DATABASE 


DATABASE 


Flgurt  8-1 

Rastructuror  - Major  Conpononts 


Driven  by  the  translation  information  specified 
In  the  TDL  tables*  the  Restructurer  builds  the 
target  RIF  database  from  the  data  In  the  source 
RIF  database. 

to  RDBMS  database*  output  by  the  IDS  Analyzer* 
that  describes  the  data  structure  of  the  target 
RIF  database. 

■ DATABASE-INITIALIZER;  Three  ADBMS  support 
modules  that  are  called  by  the  Restructurer  to 
(respectively)  (1)  read  the  data  structure  Infor- 
mation from  the  target  SDOL  tables  and  produce 
ADBMS  DDL  text  which  describes  the  target  RIF; 

(2)  analyze  this  OOL  text  to  produce  an  ADBMS 
OBTF;  and  (3)  use  this  DBTF  to  Initialize  the 
target  RIF  database  file  so  that  records  can  be 
stored  In  It. 

: An  AOBMS  scratch  database  used  by  the  DDL 
Writer  to  produce  ADBMS  DDL  text. 

An  AOBMS  database  In  which  are  stored  the  target 
record  Instances  built  by  the  Restructurer. 

This  database  Is  used  as  Input  to  the  Writer  to 
produce  the  user's  final  IDS  target  database. 


TARGET  RIF  DATABASE: 


8.2  Restructurer  Processing  Flow 

The  restructuring  process  consists  of  two  phases.  In  Phase  I* 
general  housekeeping  functions  are  performed:  all  databases  are  opened; 
the  User  Input  Directives  are  processed;  If  directed  to  do  so.  the 
target  RIF  database  Is  Initialized;  and,  the  "POINTERS"  copy  of  the  TDL 
tables  Is  prepared.  _ 

Phase  II  Is  the  actual  restructuring  of  the  database.  The  Restruc 
turer  puts  groups  of  "compatible"  access  paths  on  a "stack",  and  uses 
this  "stack"  to  exhaustively  access  all  source  record  Instances  (repre- 
sented by  the  combined  access  paths)  In  a pseudo-pre-order  tree  fashion 
For  each  group  of  source  record  Instances  accessed,  the  corresponding 
target  record  Instances  are  constructed  and  stored  In  the  target  RIF 
database.  When  all  access  paths  have  been  processed,  the  Restructurer 
Is  done,  and  a statistical  sumary  Is  printed  at  the  end  of  the  Restruc 
turer  report. 


Figure  8-2  shews  the  prototype  control  card  deck  setup  for  nmnl 

y . _ . , * _ _ i ..J  A.J  — — _ f%\  — ■ - - — — 


make  temporary  copies 
copy  the  target  RIF 


the  Restructurer.  There  are  three  activities: 
of  all  databases,  (2)  run  the  Restructurer,  and 
back  to  the  permanent  file. 
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0040 
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0260 
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0340 
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I DENT 
NOTE 
NOTE 
NOTE 
NOTE 
NOTE  * 
NOTE 
NOTE 
UTILITY 
NOTE 
FUTIL 
PRMFL 
FILE 
NOTE 
'FUTIL 
PRMFL 
FILE 
NOTE 
FUTIL 
PRMFL 
FILE 
NOTE 
FUTIL 
PRMFL 
FILE 
NOTE 
FUTIL 
PRMFL 
FILE 
NOTE 
FUTIL 
PRMFL 
FILE 
NOTE 
NOTE 
NOTE 
NOTE 
NOTE 
NOTE 
EXECUTE 
LIMITS 
PRMFL 
FILE 
PRMFL 
NOTE 
NOTE 
NOTE  . 
NOTE 
NOTE 
FILE 
FILE 
FILE 
FILE 
FILE 
FILE 


YOUR-IDENT. LABEL 

♦a************** *******************  **  **  ******  *»**»***»★ 

* ACTIVITY  01  — ALL  DATABASES  TO  RE  USED  PY  THE  * 

* RESTRUCTURER  ARE  COPIED  FIRST  TO  PROTECT  THE  * 

♦ ORIGINALS.  RE  SURE  TO  PUT  THE  CORRECT  SIZES  * 

★ (IN  RANDOM  LINKS)  ON  THE  SFILE  CARDS'.  * 

**************** ********************* *★★**♦** ********** 


01 .02.RC0PY/1F/' 

01. «,R.**tSOURCE  RIF  DATABASE*** 

02. X0S.***S0URCE  RIF  DATABASE  SIZE*** 

0J#04,RC0PY/IF/ 

03. N.R.***TARUET  RIF  DATABASE*** 

04. X I S«***TARGET  RIF  DATABASE  SIZE*** 

05.06.  ROPY/ 1 F/ 

05. R,R,***TDL  TABLES  DATABASE*** 

06. X2S.***TDL  TA«LES  DATABASE  SIZE*** 

07.0B.RG0PY/I F/ 

07. P.R.***TDL  TABLES  DATABASE*** 

08. X3S,***TDL  TABLES  DATABASE  SIZE*** 

/ 

09, IO.RCOPY/IF/ 

09.  », R.***TARGET  SDDL  TABLES  DATABASE*** 

10. X4S,***TARGET  SDDL  TABLES  DATABASE  SIZE*** 

1 1 , 12.RC0PY/I F/ 

1 1. R.P.***DDL-WRITEP  WORK  DATABASE*** 

12. X5S. I2R 

* ♦★★♦★★★★Or*************************  ******************** 

* ACTIVITY  02  — PUN  THE  RESTRUCTURER.  NOTE  THAT  * 

* THE  SLIMITS  CARD  MUST  RE  ADJUSTED  FOR  EACH  * 

* PARTICULAR  RESTRUCTURING  JOB.  * 

*★** *********  ******  ★****************^***-*************'** 
nttUD  MDCCT  ' 

CPU -T  IMF . CORE . -5K , OUTPUT-L I NE-L I M IT 
R*.P.S.***RESTRUCTURER  R*  FILE*** 

H*..40R 

TR,R,R,***TRANSLATOR  LIBRARY*** 

THE  FOLONING  SIX  *FILE  CARDS  CORRESPOND 
TO  THE  SIX  DATABASES  COPIED  IN  ACTIVITY  01 


10. X0R 

11. XIS 

12. X2R 

13. X3R 

14. X4R 

15. X5R 


SOURCE  PIF 

TARGET  RIF  (SAVED  FOR  ACTIVITY  03) 

'NAMES'  TDL  TABLE*5 

'POINTERS'  TDL  TABLES 

TARGET  SDDL  TABLES 

DDL -NR  ITER  WORK  DATARASE 

Figure  8-2 


Prototype  Rtstructurer  Control  Card  St tup 


THE  FOLLOWING  FOUR  $FILE  CARDS  ARE  USED 
IN  THE  PREPARATION  OF  THE  TARGET  RIF  FOP 
RESTRUCTURING 

01, NULL  OUTPUT  SINK  (DDLA.  DPI NT) 

02  DDL  TEXT  FOR  TARGET  RIF 

03  DBTF  FOR  TARGET  RIF 

04  USER  HASH  INPUT  FILE  TO  DSTNT 


05.. COPY 


INCLUDED  HERE  SHOULD  RE  EITHER 

1)  USER-INPUT  STATEMENTS.  OR 

2)  S SELECT A TO  FILE  CONTAINING  USER 
INPUT  STATEMENTS 


ErtDCOPY 


0770 

07*0 


NOTE  * ACTIVITY  03  — COPY  THE  NEW  TARGET  RIF  DATABASE 

NOTE  * BACK  TO  THE  PERMANENT  FILE.  IF  THE  RESTRUCTURER 

NOTE  * ENCOUNTERED  AN  ERROR  IN  ACTIVITY  02.  THE  $IF  CARD 

NOTE  * WILL  PREVENT  OVER-WRITING  THE  OLD  TARGET  DA. ABASE 

NOTE  * FILE  WITH  THE  (POSSIBLY  INCONSISTENT)  NEW  ONE'. 

NOTR  »★»»»  »»  ************  MO  »♦★»»*» »**»★♦★★**★★★*»  A 
IF  “ 35.ENDJ0B 

UTILITY 

FUTIL  01 .02.RC0PY/IF/ 

FILE  0I.X1R 

PRMFL  02. W.R. ★♦★TARGET  RIF  DATABASE*** 

ENDJOB 


0<iD0 
0810 
OS  0 

oa_o 

0840 

o«no 

Ob  0 


Figure  8*2  (cont'd) 
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NOTES 

Standard  $IDENT  card 

$PRMFL  cards  for  all  required  databases 


(LIMITS  card  for  Restructurer  run 
$PRMFL  for  Restructurer  R*  file 
$PRMFL  for  Translator  Library  file 
Must  be  replaced  with  User  Input  Directives 
Target  RIF  copied  back  to  this  $PRMFL  file. 


8.4  Activity  01  Control  Cards 

Figure  8-3  shows  the  control  cards  for  Activity  01.  This  activity 
makes  temporary  copies  of  all  databases  to  be  used  by  the  Restructurer 
In  Activity  02. 


8.4.1  File  Code  Assignments 

lines  0130-0140:  The  source  RIF  database  (output  of  the  Reader) 

should  be  assigned  to  file  code  01  via  the 
$PRMFL  card  on  line  0130.  The  correct  size 
parameter  must  be  Inserted  In  the  $FILE  card 
on  line  0140.  It  must  be  at  least  as  large  as 
the  random  file  containing  the  source  RIF 
database,  and  may  be  larger.  For  example.  If 

(1)  Source  RIF  In  MICHIGAN/SOURCEDB , and 

(2)  SOURCEDB  Is  55  lllnks, 

then  lines  0130-0140  should  be 

0130$  PRMFL  01,  R,  R,  MICHIGAN/SOURCEDB 
0140$  FILE  02,  XOS,  5f 

Note  that  5 random  links  • 60  lllnks,  more  than 
sufficient  to  hold  SOURCEDB.  SOURCEDB  Is 
copied  to  a temporary  file  (02)  and  saved  for 
the  next  activity  with  LUD  XO. 

Lines  0170-0180:  The  target  RIF  database  should  be  assigned  to 

fne  code  03  via  the  $PRMFL  card  on  line  0170. 

A corresponding  size  parameter  should  appear  on 
line  0180.  However,  unlike  the  source  RIF  data- 
base, the  target  RIF  database  must  be  an  Integral 
multiple  of  12  lllnks.  and  the  size  parameter  on 
the  SHLe  card  must  match  exactly.  The  reason 
for  this  Is  that  after  the  Restructurer  finishes 
storing  records  In  the  target  RIF,  the  temporary 
cooy  Is  copied  back  to  the  permanent  file  (Activity 
03).  Since  temporary  files  are  always  multiples 
of  12  lllnks,  the  target  RIF  must  also  be  a 
multiple  of  12  lllnks  so  that  a copy  can  be  made 


LINE  NUMBER 
0020 

0130,  0170,  0210 
0250,  0290,  0330 

0420 

0430 

0450 

0690-0740 

0880 
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o[lo 
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0180 
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02-70' 
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NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

UTILITY 

NOTE 

FUTIL 

PRMFL 

FILE 

NOTE 

FUTIL 

PRMFL 

FILE 

NOTE 

FUTIL 

PRMFL 

FILE 

NOTE 

FUTIL 

PRMFL 

FILE 

NOTE 

FUTIL 

PRMFL 

FILE 

NOTE 

FUTIL 

PRMFL 

FILE 


»★★★»★»★♦♦★»»★★★★★★ ** ** ** ****** ★»★★★★★»★★★ ***** 

★ ACTIVITY  01  — ALL  DATA RASES  TO  PE  USED  PY  THE  * 

★ RESTRUCTURER  ARE  COPIED  FIRST  TO  PROTECT  THE  * 

★ ORIGINALS.  RE  SURE  TO  PUT  THE  CORRECT  SIZES  ★ 

★ (IN  RANDOM  LINKS)  ON  THE  SFILE  CARDS.  ★ 

»*****»» hhlrk-kitk ■irk* -kirk irk iririHrir 


01 .02.RC0PY/IF/ 

01 , H,R.***SOURCE  RIF  DATABASE*** 

02 .  XOS . *** SOURCE  RIF  DATABASE  SIZE*** 

03.04, RCOP Y /IF/ 

03. W.R ,***TARGET  RIF  DATABASE*** 

04 ,  X I S, ***TAROET  RIF  DATABASE  SIZE*** 

05. 06, RCOP Y/ IF/ 

05, R,R.***TDL  TABLE?  DATABASE*** 

06. X2S. ***TDL  TABLES  DATABASE  SIZE*** 

0 7, 08. RCOP Y/ IF/ 

07. R, R, ***TDL  TABLES  DATABASE*** 

08. X3S.***TDL  TARLES  DATABASE  SIZE*** 

09, 10. RCOP Y/ IF/ 

09, R.R,***TARGET  SDDL  TARLES  DATABASE*** 

10, X4S.***TARGET  SDDL  TABLES  DATABASE  SIZE 

II, I2.PC0PY/IF/ 

I I ,R,R,***DDL -WRITER  WORK  DATABASE*** 
I2.X5S. I2R 


Figure  8-3 

Activity  01  Control  Cards 


0 


Lines  0210-0220: 


Lines  0250-0260; 


Lines  0290-0300: 


from  and  later  copied  back  to  the  same  file. 

The  target  RIF  Is  copied  to  a temporary  file 
(04)  and  saved  for  the  next  activity  with  LUD  XI. 

The  TDL  tables  database  should  be  assigned  to 
file  code  05  via  the  $PRMFL  card  on  line  0210. 

A corresponding  size  parameter  should  appear  on 
line  0220.  The  size  of  the  temporary  file  may 
be  larger  than  the  permanent  file,  as  In  the 
example  for  the  source  RIF  database.  The  TDL 
tables  are  copied  to  a temporary  file  (06)  and 
saved  for  the  next  activity  with  LUD  X2.  This 
copy  will  become  the  "NAMES"  copy  of  the  TDL 
tables  In  Activity  02  (see  Section  8.1  for  an 
explanation  of  "NAMES"  vs.  "POINTERS"  TDL  tables). 

Same  as  lines  0210-0220.  The  same  TDL  tables 
database  (file  code  07)  Is  copied  to  a temporary 
file  (08)  and  saved  for  the  next  activity  with 
LUD  X3.  This  copy  will  become  the  "POINTERS" 
copy  of  the  TDL  tables  In  Activity  02. 

The  SODL  tables  database  for  the  target  database 
should  be  assigned  to  file  code  09  via  the  SPRMFL 
card  on  line  0290.  A corresponding  size  parameter 
should  appear  on  line  0300  (may  be  larger  than 
permanent  file  size).  The  target  SDOL  tables  are 
copied  to  a temporary  file  (10)  and  saved  for  the 
next  activity  with  LUD  X4. 

The  DDL  Writer  Work  Database  (restored  from  the 
SYSGEN  tape)  should  be  assigned  to  file  code  11 
via  the  SPRMFL  card  on  line  0330.  Its  size  Is 
fixed  at  12  random  links  * 144  1 1 Inks . The  Work 
Database  Is  copied  to  a temporary  file  (12)  and 
saved  for  the  next  activity  with  LUD  X5. 


8.4.2  User  Parameters 

No  user  parameters  are  required  for  Activity  01. 

8.4.3  Output  Interpretation  and  Example 


The  output  of  Activity  01  Is  the  standard  $UTILITY  output  and  is 
not  shown  here. 

8.4.4  Errors 

Any  error  messages  will  be  standard  control  card  or  SUTILITY  messages 
documented  In  H-6000  documentation.  However,  the  following  are  some  of 
the  more  elementary  sources  of  errors: 

1.  Database  file  Is  sequential  Instead  of  random. 

2.  Size  parameter  on  $FILE  card  Is  too  small. 

3.  File  name  spelled  Incorrectly. 


Line  0330: 


r 


8.S  Activity  02  Control  Cards 

Figure  8-4  shows  the  control  cards  for  Activity  02.  This  activity 
actually  executes  the  Rastructurer  and  produces  a temporary  copy  of  the 
target  RIF  database. 


8.5.2  User  Parameters 

There  are  three  areas  of  user  Input  to  the  Aestructurer  run: 

(1)  the  $ LIMITS  card,  (2)  the  User  Input  Directives  on  file  code  05, 
and  (3)  optional  use  of  (REMOTE  and  $PRMFL  cards  for  file  codes  01-04 


8.5.2. 1 The  (LIMITS  Card 

The  (LIMITS  card  on  line  0420  oust  be  replaced  with  a suitable 
(LIMITS  for  each  particular  run.  The  following  rules -of -thumb  apply  to 
runs  made  with  #EXECUTION-MONITOR-OFF  (see  Section  8.5.2. 2): 

1.  The  CPU  tine  required  varies  roughly  linearly  with  the  sire  of 
the  database  to  be  restructured.  However,  processor  time 
requirements  will  be  greater  for  runs  with  more  complex  access 
paths,  more  qualifications,  and  for  runs  that  use  user  conversion 
and  qualification  routines.  The  general  rule  Is:  take  the 
number  of  record  Instances  In  the  larger  of  the  two  (source  and 
target)  databases.  Divide  this  number  by  thirty  (30).  The 
result  Is  the  number  that  goes  on  the  (LIMITS  card  for  CPU-TIME. 
For  example,  suppose  the  source  database  contained  2000  record 
Instances,  and  the  target  database  was  expected  to  have  3000 
record  Instances.  Then  3000t30  ■ 100,  and  the  (LIMITS  card 
would  look  like: 

( LIMITS  100,  CORE.-5K.OUTPUT-LINE-LIMIT 

Note:  this  method  provides  a gross  over-estimate  so  that  a 
Rastructurer  run  will  not  terminate  due  to  lack,  of  CPU  time 
requested.  After  a few  runs,  the  user  should  develop  a feeling 
for  how  much  time  a particular  run  will  take,  and  may  cautiously 
lower  his  CPU  limit  If  It  Is  to  Ms  advantage. 


i 0450 
0460 
« C370 

I oiao 

! 0490 
0400 
! 04.1 0 
0420 
0430 
0440 
0450 
| 0460 
0470 
! 0480 
0490 
0500 
0510 
0520 
! 0a30 
0540 
0550 
0560 
0570 
0530 
0590 
0600 
0610 
06 20 
0630 
064  0 
0650 
06o0 
Co  70 
06b0 
009  0 
0700 
0/10 
0/20 
0 /30 
0740 
0750 


NOTH 

note  ★»»**»♦»»» 

NOTE  * ACTIVITY  02  — RUN  THE  RESTRUCTU! 

NOTH  * THE  SLIGHTS  CARD  MUST  RE  ADJUSTEI 

NOTE  * PARTICULAR  RESTRUCTURING  JOB. 
NOTH  *****  **»«»**★★»★»»»»**»*★★★★★★★★★★★★ 

EXECUTE  DUMP.NREST 

LIMITS  CPU  -TIME.  CORE « -5K . OUTPUT  '-LINE-LIMIT 
PRMFL  R*,R.S.***RESTRUCTUREB  R*  FILE*** 
FILE  H*..40R 

PRNFL  TR#R*R-»***TRANSLAT()R  LIBRARY*** 

NOTE 
NOTE 
NOTE 
NOTE 
NOTE 
FILE 
FILE 
FILE 
FILE 
FILE 


THE  PQLONING  SIX  SFILE  CAPDS  CO RRESPOND 
TO  THE  SIX  DATABASES  COPIED  IN  ACTIVITY  01 


SOURCE  RIF 

TARGET  RIF  (SAVED  FOR  ACTIVITY  03) 
'NAMES'  TDL  TARLE* 

'POINTERS'  TDL  TABLES 
TARGET  SDDL  TABLES 
DDL -WRITER  WORK  DaTARASE 


NOTE 
NOTE 
NOTH 
NOTE 
NOTE 
FILE 
FILE 
FILE 
FILE 
NOTE 
NOTE 

DATA  05.. COPY 
NOTE 
NOTE 
NOTE 
NOTE 
NOTE 
NOTE 
ENDCOPY 


THE  FOLLOWING  FOUR  SFILE  CARDS  are  USED 
IN  THE  PREPARATION  OF  THE  TARGET  RIF  FOR 
RESTRUCTURING 


01  .NULL 

02 

03 

04 


OUTPUT  SINK  (DDLA.  DR  I NT) 

DDL  TEXT  FOP  TARGET  RIF 

DRTF  FOR  TARGET  RIF 

USER  HASH  INPUT  FILF  TO  OR  I NT 


INCLUDED  HERE  SHOULD  RE  EITHER 

1)  USER-INPUT  STATEMENTS,  OR 

2)  $ SELECT A TO  FILE  CONTAINING  USER 
INPUT  SfATEMENTS 


Flgur*  8-4 

Activity  02  Control  Cards 
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2.  The  CORE  required  will  almost  always  be  66K,  since  the  Restruc- 
turer  buffers  and  storage  are  the  same  for  each  run.  The  only 
time  more  core  Is  needed  Is  If  user  qualification  and/or  con- 
version routines  are  used  (see  Section  4.2.3  on  user  qualification 
and  conversion  routines,  and  Section  8.7  for  modifications  to 
Restructurer  control  cards). 

3.  The  default  OUTPUT-LINE-LIMIT  for  a {EXECUTE  activity  (as  Is 
Activity  02)  Is  more  than  sufficient  if  #EXECUTION-MONITOR=OFF. 

If  runnlngwith  #EXECUTI0N-M0NIT0R»0N  (see  Section  8.5. 2.2),  the 
following  adjustments  should  be  made  to  the  estimates  presented  above: 

4.  Increase  the  number  obtained  In  (1)  above  for  CPU-TIME  by  25%. 

5.  The  Execution-Monitor  output  Is  quite  lengthy  and  Is  usually 
only  needed  when  debugging  a very  stubborn  bug  In  the  user's 

TDL.  If  It  is  needed,  only  the  access  paths  being  debugged  should 
be  active  for  the  run  (see  Section  8.5. 2.2).  The  general  rule 
Is:  take  the  number  of  record  Instances  In  the  larger  of  the 
two  databases.  If  only  a few  access  paths  are  being  used,  this 
number  may  be  scaled  down  by  a factor  equalling  the  fraction  of 
the  source  database  Instances  represented  by  the  active  access 
paths.  In  either  case,  multiply  this  number  by  fifty  (50). 

This  is  the  number  that  goes  on  the  {LIMITS  card  for  OUTPUT-LINE- 
LIMIT. 

Presented  here  Is  a complete  example  of  how  to  estimate  the  {LIMITS 
card.  Assume  the  following: 

a.  Source  database:  2000  record  Instances  ' 

b.  Target  database:  3000  record  instances 

c.  No  user  qualification  or  conversion  routines 

Then,  If  #EXECUTI0N-M0NIT0R»0FF, 

CPU- TIME  « 3000  i 30  - 100 

CORE  « 66K 

OUTPUT-LINE-LIMIT  not  needed 
And  the  {LIMITS  card  Is 

{ LIMITS  100,66K,-5K 
If  #EXECUTION-MONITOR*ON , then 

CPU-TIME  • 100  ♦ (.25)100  » 125 

OUTPUT-LINE-LIMIT  » 3000  x 50  - 150,000 


And  the  {LIMITS  card  Is 

{ LIMITS  1 25, 66K,-5K, 150000 


The  User  Input  Directives  are  read  by  the  Restructurer  from  file  code 
05,  and  are  used  to  control  various  aspects  of  the  Restructurer  run.  Lines 
0690-0740  must  be  replaced  (l.e. , the  {NOTE  cards  must  not  appear  between 
lines  0680  and  0750  In  final  form)  with  either  the  actual  User  Input  Directives 
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op  with  a $SELECTA  to  an  ASCII  file  containing  them.  A description  of  the 
various  directives  Is  presented  here,  followed  by  an  example. 

1.  All  User  Input  Directives  begin  with  a pound  sign  (#).  However, 
since  TSS  strips  off  a pound  sign  Inmedlately  following  a file 
line  number,  two  pound  signs  should  appear  with  the  directive 
so  that  when  the  User  Input  Processor  reads  file  code  05,  each 
directive  begins  with  one  pound  sign. 

2.  If  a pound  sign  is  desired  as  the  first  character  of  a TDLAP 
name,  two  pound  signs  should  be  used  (##).  Again,  since  TSS 
strips  off  one  pound  sign,  three  pound  signs  must  follow  the 
file  line  number  to  Indicate  that  the  TDLAP  name  begins  with 
one  pound  sign.  Pound  signs  within  a name  need  no  special 
treatment. 

3.  No  embedded  blanks  are  allowed  In  any  User  Input  Directives. 

4.  User  Input  Directives  must  begin  In  column  one  (1).  The  first 
blank  encountered  on  a line  terminates  the  line.  User  Input 
Directives  must  be  one-to-a-llne  and  may  not  extend  over  more 
than  one  line. 


5.  The  following  are  legal  User  Input  Directives: 
a.  #TRANSLATI0N-NAME*48-character-name 


This  directive  allows  the  user  to  put  a label  on  the  Restructurer 
output.  The  label  may  be  up  to  48  nonblank  characters,  and  will 
appear  In  the  User  Input  Summary  and  at  the  top  of  the  Statistical 
Sunmary  (see  Section  8.5.3). 

»•  ™ -{SZE 

This  directive  determines  whether  or  not  the  target  RIF  database 
Is  Initialized  before  restructuring  begins. 

INITIALIZE  - the  copy  of  the  target  RIF  database  file  Is 
Initialized  before  restructuring.  The  contents  of  the 
permanent  file  are  not  modified  until  Activity  03. 

CONTINUE  - the  copy  of  the  target  RIF  database  file  is  not 
modified  In  any  way.  The  target  RIF  Is  assumed  to  have 
been  Initialized  (e.g.,  by  a previous  run)  and  may 
contain  restructuring  output  (target  records  ) from 
previous  Restructurer  runs.  The  output  from  the  current 
run  will  simply  be  added  to  whatever  already  exists  In 
the  target  RIF  database. 

c.  #execution-monitor*/°Jf 

Thls  directive  turns  the  Restructurer  debug  output  on  or  off: 

ON  - debug  output  appears  along  with  the  Restructurer  report 
on  report  code  06. 

OFF  - no  debug  output  is  printed. 

Note:  error  messages  always  appear  on  report  code  06,  Independent 
of  the  lEXECUTION-MONITOR  * directive. 
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d.  IACTIVE- TDLAPS 

This  directive  indicates  that  the  following  TDLAPS  are  to  be  "active", 

l.e. , used  to  build  target  records  during  the  Restructurer  run.  TDLAP 
names  must  appear  one  per  line  immediately  following  the  directive  and 
must  start  In  column  one  (1).  The  appearance  of  the  keyword  ALL-TDLAPS- 
ACTIVE  Instead  of  a TDLAP  name  Indicates  all  TDLAPS  are  to  be  used  for 
restructuring  during  the  run.  Other  rules: 

1.  If  ALL-TDLAPS-ACTIVE  is  used,  it  may  not  be  followed  by  a TDLAP 
name. 

2.  Either  ALL-TDLAPS-ACTIVE  or  at  least  one  TDLAP  name  must  follow 
the  #ACTIVE-TDLAPS  directive. 

3.  The  list  of  TDLAP  names  is  terminated  by  an  end-of-flle  or  another 
User  Input  Directive. 

4.  All  occurrences  of  a particular  TDLAP  name  after  the  first  occurrence 
are  Ignored  and  do  not  produce  an  error  message. 

This  directive  is  particularly  useful  for  debugging  one  access  path  at  a 
time,  and  for  performing  large  restructuring  operations  a little  at  a time. 
For  example,  a particular  restructuring  job  may  take  longer  than  the 
amount  of  continuous  computer  "up"  time  available.  In  cases  like  this, 
the  user  may  make  the  first  Restructurer  run  with  #RUN*INITIALIZE  and  one 
or  two  access  paths  "active".  Each  succeeding  run  is  then  made  with 
#RUN*CONTINUE  and  one  or  two  different  access  paths  "active"  until  all 
access  paths  have  been  processed.  Thus,  the  first  run  initializes  the 
target  RIF  database  and  stores  the  target  records  built  from  the  "active" 
access  paths.  The  target  RIF  database  is  not  initialized  on  succeeding 
runs;  the  target  records  from  each  active  access  path  are  stored  in  the 
same  database  as  In  the  first  run  until  all  restructuring  is  completed. 

The  content  of  a target  RIF  database  produced  in  this  way  is  logically 
equivalent  to  a target  RIF  produced  in  a single  run.  Note,  however,  that 
if  the  source  RIF  database,  source  SDDL  tables,  and/or  target  SDDL  tables 
are  regenerated  part  way  through  this  restructuring-by-parts  process,  pre- 
vious runs  may  become  inconsistent  and  will  have  to  be  rerun  from  scratch. 

e.  #USER-HASH- INPUT 

This  directive  indicates  that  the  following  lines  should  be  input  to  the 
ADBMS  Database-Initializer.  They  will  be  used  to  modify  the  standard 
ADBMS  hashing  algorithm  that  Is  used  to  store  records  In  the  target  RIF 
database.  Use  of  this  directive  is  necessary  only  In  unusual  cases  when, 
for  a particular  target  RIF  database,  the  standard  record  storage  algorithm 
breaks  down  and  a different  algorithm  Is  required.  This  event  necessitates 
a thorough  analysis  of  the  data  before  attempting  to  alter  the  record 
storage  algorithm.  Data  Translation  Project  personnel  should  be  consulted 
In  the  event  that  problems  of  this  nature  arise. 

f.  #END- USER- INPUT 

This  directive  signals  the  end  of  the  User  Input  Directives,  and  scanning 
of  the  directives  terminates  when  this  directive  is  encountered.  If 
an  end-of-flle  Is  encountered  before  this  directive.  It  is  assumed  that 
the  end  of  the  User  Input  Directives  has  been  reached. 


Further  Notes  and  Rules 


6.  The  User  Input  Directives  are  order-independent, 

7.  Any  errors  detected  while  processing  the  User  Input  Directives  will 
result  In  the  cancellation  of  the  Restructurer  run.  However,  all  directives 
are  always  processed  for  errors. 

8.  Any  directive  appearing  more  than  once  Is  considered  an  error. 

9.  Certain  directives  must  appear  for  each  run: 
a,  #RUN* 

b!  #EXECUTI ON- MON I T0R» 

c.  #ACTIVE-TDLAPS,  followed  by  at  least  one  TDLAP  name  or  by 
ALL-TDLAPS-ACTIVE. 

If  any  of  the  above  directives  Is  missing.  It  Is  considered  an  error. 

10.  Optional  directives  are: 

a.  ITRANS  LATI ON- NAME* 

b.  IUSER-HASH- INPUT 

c.  IEND-USER- INPUT 

The  absence  of  one  or  more  of  these  Is  not  an  error. 

11.  Following  are  two  examples  of  User  Input  Directives: 

EXAMPLE  #1 

File  Line  No.  Directive 

10  ##TRANSLATION-NAME«OLD-TO-NEW 

20  ##RUN»INITIALIZE 

30  ##EXECUTI0N-M0NIT0R*0FF 

40  ##ACTIVE-TDLAPS 

50  ALL-TDLAPS-ACTIVE 

60  ##END-USER- INPUT 

Comments  on  Example  #1 

Line  10:  Label  for  output 

Line  20:  Target  RIF  database  Is  to  be  Initialized 

Line  30:  No  debug  output  Is  to  be  printed 

Line  40:  The  following  TDLAPS  are  to  be  used  during  the  run: 

Line  50:  All  of  them 

Line  60:  End  of  User  Input  Directives 


EXAMPLE  #2 


Directive 


##RUN*CONTINUE 

##EXECUTI0N-M0NIT0R*0N 

##ACTIVE-TDLAPS 

PEOPLE-REC 

###OFFSPRING 

end-of-flle 


[J 

w 
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Comments  on  Example  #2 

Line  10:  Target  RIF  database  not  initialized;  records  are  stored  In 
database  along  with  content  from  previous  runs. 

Line  20:  Debug  output  will  be  printed  on  report  code  06. 

Line  30:  The  following  TDLAPS  will  be  "active"  for  the  run. 

Lines  40,50:  The  TDLAPS  "PEOPLE-REC"  and  "#0FFSPRIN6"  will  be  active. 

Line  (60):  Nonexistent;  end-of-flle  Indicates  end  of  User  Input  Directives 


Note:  Unlike  the  examples  above,  no  Intervening  blanks  should  appear  be- 
tween the  file  line  numbers  and  the  User  Input  Directives, 

8.5. 2. 3 Optional  SREMOTEs  and  $PRMFLs 

If  desired,  file  codes  01,  02,  03,  and  04  may  be  assigned  to 
permanent  files  via  $PRMFL  cards  (with  WRITE  permission)  for  later 
examination.  In  addition,  line  0620  may  be  replaced  by: 

0620  $ REMOTE  01 

which  will  force  (usually  unnecessary)  output  from  the  DDL  Analyzer  and 
Database  Initializer  to  appear  on  report  code  01.  This  output  may  be 
useful  if  errors  occur  in  one  or  both  of  these  modules. 


8.5.3  Output  Interpretation  and  Example 

The  Restructurer  Report  appears  on  report  code  06  of  Activity  02. 
(This  description  Is  for  #EXECUTI0N-M0NIT0R=0FF).  At  the  top  of  the 
first  page  will  appear 

######RESTRUCTURER  REPORT- VERSION  IIA,  RELEASE  2 ####### 

Any  errors  that  occur  between  this  message  and  the  next  will  appear  on 
this  page.  However,  If  all  goes  well,  the  remainder  of  the  first  page 
should  be  blank.  At  the  top  of  the  next  page  will  be  the  message: 

PHASE  I - PROCESS  USER  INPUT  FILE 

User  Input  Processor  error  messages.  If  any,  will  follow.  However,  If 
no  errors  are  detected,  the  remainder  of  the  page  will  be  blank. 

At  the  top  of  the  next  page  (following  any  error  messages)  will  be 
the  User  Input  Sumriary.  The  summary  gives  the  status  of  each  of  the 
User  Input  Directives  and  Information  regarding  the  preparation  of  the 
target  RIF  database  (If  any  occurred).  An  example  of  the  User  Input 
Summary  Is  shown  In  Figure  8-5.  If  all  User  Input  was  correct,  the  last 
message  of  the  suumary  will  be  "USER  INPUT  ACCEPTABLE." 

The  top  of  the  next  page  should  be  headed  by  the  message: 

PHASE  II  - RESTRUCTURER  BEGINS 

with  the  remainder  of  the  page  blank  (unless  there  are  error  messages). 
Each  succeeding  page  will  (again.  If  there  are  no  errors)  show  a small 
summary  of  each  stack  built  by  the  Stack  Builder.  An  example  Is  shown 
In  Figure  8-6.  The  stack  number  simply  Indicates  the  order  In  which 
the  stacks  were  built  and  accessed.  A list  of  the  access  paths  that 
were  stacked  together  on  that  stack  follows.  Any  error  messages  resulting 
from  the  accessing  of  the  records  on  the  stack  will  follow  this  list, 
ending  with  a message  Indicating  whether  or  not  the  stack  was  successfully 
accessed. 


1 a.W.iufl. .s*.  to-  AJfv  -j:  a^hLc.-k... 


USER"  INPUT  SUMMARY 


OPTION 


STATUS 


TRAnSLaTION-wAVE 
Ru  N 

£XECUTION-W()MTOR 
ACTI VE-TDLAPS 
USER-HASH- INPUT 


NEW-PRESIDENTIAL-TO-DECADE 

INITIALIZE 

OFF 

A LL-TDL * PS-ACTIVE 
NONE  SPECIFIED 


0 BAD  CARDS  DETECTED 


»*)  ERRORS  DETECTED  IN  USER  INPUT 
#####*rrIF  DDL  SUCCESSFULLY  WRITTEN###### 


DATA  BASS  TABLE  FILE  WRITTEN 


DATA  BASE  INITIALIZED  WITH 


HASH  DATA  RASE  HAS 


5 HASH  PAGES  AND  0 OVERFLOW  PAGES 


THERE  ARE  1 BUCKETS/PAGE 


HASH  IS  REMAINDER  OF  ( ( PK  REDUCED  TO  1 WORD  BY  EXCLUSIVE  OR)/ 


USER  INPUT  ACCEPTABLE 


Figure  8-5 

Example  Output  - User  Input  Summary 


THE  FOLLOWING  ACCESS  PATHS  HAVE  BEEN  SUCCESSFULLY  STACKED  ON  STACK  NO 
<rRES  > 

<MAPR  > 


<OCCUPAT!ON  > 


SOURCE  INSTANCES  FOR  STACK  NO.  1 EXHAUSTED*  NO  ERRORS  DETECTED 


Figure  8-6 
Stack  Summary 


If  there  were  no  errors  In  the  run,  the  page  following  the  summary  for 
the  last  stack  will  be  headed  by  the  message: 

PHASE  II  COMPLETE  - RESTRUCTURE!!  TERMINATING 

If  errors  occurred  during  the  run,  this  message  will  be  replaced  by  an 
appropriate  error  message.  On  this  and  the  following  pages  appear  the 
Statistical  Summary.  The  source  database  summary  follows  the  above  mes- 
sage; the  target  database  summary  begins  at  the  top  of  the  page  following 
the  source  database  summary;  and  the  access  paths  summary  similarly  follows 
the  target  database  summary.  Figures  8-7,  8-8,  and  8-9  respectively  show 
examples. 

Following  are  explanations  of  Figures  8-7,  8-8,  and  8-9. 

Figure  8-7:  Source  Database 

The  fTRANSLATION-NAME  appears  under  "STATISTICAL  SUW1ARY."  (If  none  was 
specified  via  the  use  of  the  directive,  the  space  will  be  blank).  Infor- 
mation regarding  each  source  record  type  Is  read  across  the  columns  from 
left  to  right. 

"SOURCE  RECORD  TYPE"  column:  the  six-character  ADBMS  name  (as  It  appears 
In  the  source  SDDL  tables  database)  of  each  source  record  type  that  was 
accessed  at  least  once  (l.e. , at  least  one  attempt  to  retrieve  an 
Instance,  actual  or  null,  was  successful). 

"ACCESSES  FOR  THIS  TYPE"  column:  the  number  of  actual  record  Instances 
accessed  (retrieved)  for  each  source  record  type.  This  number  does  not 
Include  null  Instances. 

"PASSED  QUALIFICATION"  column:  for  each  source  record  type,  the  number 
of  record  Instances  that  satisfied  qualification  criteria.  This  number 
Includes  null  Instances. 

"FAILED  QUALIFICATION"  column:  for  each  source  record  type,  the  number 
of  record  Instances  *hat  did  not  satisfy  qualification  criteria.  This 
number  also  Includes  null  Instances. 

The  TOTALS  at  the  bottom  of  each  column  are  simply  the  sums  of  each 
column.  Note  that  In  general,  as  In  Figure  8-7,  the  sum  of  columns  3 
and  4 do  not  add  up  to  give  the  corresponding  number  In  column  2.  The 
reason  for  this  Is  twofold:  (1)  column  1 counts  actual  record  Instances 
retrieved,  not  Including  null  Instances,  while  columns  3 and  4 do  Include 
null  Instances,  (2)  when  two  or  more  compatible  access  paths  "share"  a 
record  on  the  stack,  the  record  need  be  retrieved  only  once;  then  all 
qualifications,  one  for  each  access  path,  may  be  performed  on  the  same 
record  without  the  need  to  access  It  again. 


Figure  8-8:  Target  Database 


Always  starts  at  the  top  of  a new  page.  The  structure  Is  similar  to  that 
of  the  source  database  summary. 

"TARGET  RECORD  TYPE"  column:  the  six-character  ADBMS  name  (as  It  appears 
In  the  target  SDDL  tables  database)  of  each  target  record  type  for  which 
at  least  one  Instance  was  created  and  stored  In  the  target  RIF. 

"TOTAL  RECORDS  CONSTRUCTED"  column:  the  total  number  of  record  Instances 
of  each  record  type  that  the  Restructurer  attempted  to  create.  This 
Includes  dppllcate  records. 


'HASH  II  COMPLETE  - RESTRUCTURE#  TERMINATING 
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"DUPLICATE  RECORDS  CONSTRUCTED"  column:  the  number  of  duplicate  (l.e., 
had  same  primary  key  field  values)  .record  Instances  of  each  record  type 
that  the  Restructurer  attempted  to  create.  These  records  are  never 
stored  In  the  target  RIF  database  since  a duplicate  Instance  has  already 
been  stored. 

"NET  RECORDS  CONSTRUCTED"  column:  the  total  number  of  record  Instances 
of  each  record  type  that  was  stored  In  the  target  RIF  database. 


The  TOTALS  are  again  the  sums  of  each  column.  However,  for  the  target 
database  summary.  It  should  always  be  true  for  each  row  (l.e.,  target  record 
type)  that 


NET  (col. 4)  * TOTAL  (col.  2)  - DUPLICATE  (col. 3) 
Figure  8-9:  Access  Paths 
Gives  the  following  information: 


"STACK  NUMBER"  column:  these  numbers  correspond  to  the  stack  numbers 
given  with  each  short  stack  summary  earlier  In  the  report. 


"ACCESSED  SUCCESSFULLY"  column:  tells  whether  or  not  the  corresponding 
stack  was  processed  with  no  errors: 

YES  * no  errors 

NO  * errors  occurred;  results  from  this  stack  are  probably  not 
consistent. 

XXX  * a job  abort  occurred  while  processing  this  stack;  results 
are  unpredictable 


"SOURCE  ACCESSOR  TIMES  IN  MILLISEC0N0S"  columns:  gives  timing  data  for 
each  stack  In  milliseconds  (1  second  * 1000  milliseconds): 


"ELAPSED  TIME":  the  elapsed  time  for  the  accessing  of  the  stack. 
"PRQC.  TIME":  the  CPU  (processor)  time  used  for  the  accessing 

of  the  stack. 


For  example,  note  that  stack  number  1 took  an  elapsed  time  of  86.398 
seconds  to  process  while  using  up  22.137  seconds  of  processor  time.  These 
times  give  an  Indication  of  the  relative  complexities  of  and  the  number 
of  source  record  Instances  corresponding  to  the  various  access  paths. 

"ACCESS  PATH  INSTANCES  FROM  STACK"  column:  for  each  stack,  the  number 
of  access  path  Instances  from  all  the  access  paths  on  the  stack.  Each 
access  path  Instance  corresponds  to  one  record  Instance  creation  by  the 
Restructurer.  The  TOTAL  for  this  column  should  equal  the  TOTAL  for 
column  2,  "TOTAL  RECORDS  CONSTRUCTED",  from  the  target  database  summary. 

"ACCESS  PATHS  ON  STACK"  column:  a list  of  the  access  paths  on  the 
corresponding  stack.  For  example,  in  Figure  8-9,  the  access  paths  named 
PRES,  MARR,  OCCUPATION,  and  RELA  were  all  processed  together  (because 
they  were  compatible)  on  stack  number  1. 

"ACCESS  PATH  INSTANCES  FROM  A.P."  column:  same  as  "ACCESS  PATH  INSTANCES 
FROM  STACK",  except  for  each  access  path. 

The  TOTALS  are  again  the  sum  of  the  corresponding  columns.  The 
final  message  should  be  the  "DONE"  message  following  the  Access  Path  Suamary, 
as  shown  In  Figure  8-9. 
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Sot  Final  Notts  on  tht  Restructurer  Report 

1.  An  error-free  run  should  be  mostly  empty  space;  the  numerous  page 
skips  make  the  report  easier  to  analyze  In  the  case  of  numerous  errors. 

2.  The  Statistical  Summary  may  be  Inconsistent  for  runs  that  were  aborted 
or  In  which  errors  occurred. 


8.5.4  Errors 

The  Restructurer  Is  designed  to  continue  executing  in  spite  of  errors 
as  long  as  they  are  not  of  a nature  that  would  make  further  execution 
useless  (e.g. , unable  to  open  a database).  Extensive  error  messages 
are  provided  and  printed  out  on  report  code  06  along  with  the  Restructurer 
report.  Appendix  0 contains  an  explanation  of  all  Restructurer  error 
messages  and  suggests  possible  sources  of  most  errors.  

Most  Restructurer  error  messages  begin  with  six  asterisks  (******). 
IEXECUTI0N-M0NIT0R  debug  messages  alweys  begin  with  six  pound  signs  (I#####) 


8.6  Activity  03  Control  Cards 

Figure  8-10  shows  the  control  cards  for  Activity  03.  If  the 
Restructurer  run  (Activity  02)  was  successful,  the  temporary  copy  of  the 
target  RIF  database  Is  copied  back  to  the  permanent  file.  If  the  run  had 
errors  In  It,  the  $IF  card  (line  0840)  will  cancel  Activity  03  to  avoid 
destroying  the  old  contents  of  the  permanent  file  with  a bad  database. 


8.6.1  File  Code  Assignments 

Line  0880:  the  target  RIF  database  should  be  assigned  to  file  code  02 
via  the  5PRMFL  card  on  line  0880.  No  size  parameter  Is  needed.  This 
should  be  the  same  permanent  file  as  that  assigned  to  file  code  03  In 
Activity  01. 


No  user  parameters  are  required  for  Activity  03 


8.6.3  Output  Interpretation  and  Example 

The  output  of  Activity  03  Is  the  standard  $UTIIITY  output  and  is  not 


8.6.4  Errors 

Any  error  messages  will  be  standard  control  card  or  $UTILITY  errors 
documented  In  H-6000  documentation.  Common  errors  are  mentioned  In 
Section  8.4.4. 
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★★★★★•»  **  +*  ★★★★»★★  ★★  It* ******** »★★★★★*★★★★★★ 

* ACTIVITY  03  — COPY  THE  NEW  TARGET  RIF  DATABASE  * 

* BACK  TO  THE  PERWAwENT  FILE.  IF  THE  RESTRUCTURE*?  ★ 

* ENCOUNTERED  AN  ERROR  IN  ACTIVITY  02.  THE  SLF  CARD  ★ 

* WILL  PREVENT-' OVER-WRITING  THE  OLD  TARGET  DATABASE  * 

* FILE  WITH  THE  (POSSIBLY  INCONSISTENT)  NEW  ONE.  * 

35. END JOB 

01 .02.PCOPY/IF/ 

01. X1R 

02. W.R.***TARGET  RIF  DATABASE*** 


Figure  8-10 

Activity  03  Control  Cards 
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8.7  Modifications  to  Restructurer  Control  Cards  for  User  Routines 

Tha  control  card  setup  for  running  tha  Restructurer  that  was  presented 
In  Sections  8. 3-8. 6 must  be  modified  If  user  qualification  and/or 
conversion  routines  were  specified  In  the  TO.  description  (see  Section 
4.2.3).  The  object  code  for  each  user  routine  must  be  Inserted  Into  the 
Restructurer  R+  file  along  with  the  normal  Restructurer  object  code. 

The  modified  R+  file  Is  then  passed  to  Activity  02,  where  dynamic  linking 
and  loading  are  used  to  Interface  with  the  user  routines. 

Figure  8-11  shows  the  extra  control  cards  required  to  run  the 
Restructurer  with  user  routines.  This  set  of  control  cards  is  Inserted 
between  lines  0020  and  0030  of  Figure  8-2;  It  then  becomes  Activity  01. 
Activity  02  Is  now  the  IUTILITY  copy  gf  all  databases;  Activity  03,  the 
Restructurer;  and  Activity  04  copies  the  target  RIF  database  back  to  the 
permanent  file. 

Line  0030:  the  Restructurer  R*  file  (restored  from  the  SYSGEN  tape) 
must  be  assigned  to  file  code  *R  via  the  $PRMFL  card  on  line  0030. 

Line  0060:  this  card  copies  the  Restructurer  object  code  from  file  code 
*R  to  file  code  R*  up  to  the  subroutine  TDBSTA,  which  Is  the  last  subroutine 
In  the  Restructurer  R*  file.  The  object  code  for  the  user  routines  Is 
Inserted  Into  the  modified  R*  following  this  subroutine.  This  card 
should  not  be  modified  In  any  way. 

Line  0140:  "USER-NAME"  must  be  replaced  by  the  six-character  name  that 
appeared  In  a "WHEN  QUALIFIED  BY"  or  "CONVERT  WITH"  clause  In  the  user's 
TDL  description.  Remember  that  this  name  cannot  be  the  same  as  the  sub- 
routine name. 

Line  01  SO:  "SUBNAM"  must  be  replaced  by  the  subroutine  name  of  the 


Line  0160:  "OBJECT-FILE"  must  be  replaced  by  the  file  In  which  the 
user  routine  object  code  resides. 

Lines  0140-0160  are  repeated  for  each  user  routine 


Line  0430  of  Figure 


$ FILE  R*,R9R 

The  CORE  option  on  the  $LIMITS  card  (line  0420  of  Figure  8-2)  should  also 
be  Increased  from  66K  according  to  the  size  of  user  routines.  Finally, 
all  the  $N0TE  cards  In  Figure  8-11  (lines  0080-0130  and  0170-0180)  should 


be  deleted  before  Inserting  It  Into  Figure  8-2  (see  example  below) 
As  an  example,  assume  the  following  clauses  appear  In  the  TO. 


description 


WHEN  QUALIFIED  BY  UQUAL1 


CONVERT  WITH  UC0NV1 


CONVERT  WITH  UC0NV2 


.Vtitoc  ju.- : 
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Assvm  also  that  tha  user  has  written  the  following  subroutines  and 
compiled  them  Into  the  corresponding  files: 


W 


UGQNVl 

UC0NV2 


UUC0N1 

UUC0N2 


mmm 


MICHIGAN/UUC0N1 .0 
NICHI6AN/UUC0N2 . 0 


Figure  8-12  shows  the  control  cards  that  oust  be  Inserted  between 
lines  0020  and  0030  of  Figure  8-2.  Recall  also  that  line  0430  of  Figure 


I lira#  Wfcw  uwyy  wi  • ^ ” TI  T . 

8-2  oust  be  altered  along  with  the  (LIMITS  card  (line  0420),  as  specified 
above. 

A final  note  on  using  user  routines:  It  Is  suggested  that  the  user 
adopt  a naming  convention  such  as  beginning  all  "WEN  QUALIFIED  BY, 
"CONVERT  KITH,"  and  user  routine  subroutine  names  with  a double  consonant 
(e.g.,  "ZZUSER").  This  will  avoid  control  card  and  loader  errors  caused 
by  a user  routine  or  (LINK  name  having  the  same  name  as  a Restructurer 
subroutine  or  SLINK  name. 


0020 

0030 

0040 

0050 

0040 

0070 

0080 

0090 

0100 

0110 

0120 

0130 

0140 

0130 

0100 

0170 

0180 

0190 

0200 


FILEDIT 

PRMFL 

FILE 

DATA 

COPY 

INCLUDE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

LINK 

ENTRY 

8ELECTD 

NOTE 

NOTE 

ENDEDIT 

EnDCGFY 


*R,R,Sf***RESTRUCTURER  R*  FILE*** 

RSfROSrlOL 

*C? »COPY 

f'TDBSTA  LAST  SUBR*  IN  RESTR* 


THE  NEXT  THREE  CONTROL  CARDS  HUST  BE 
REPEATED  AS  A BLOCK  FOR  EACH  USER 
ROUTINE  TO  BE  INCLUDED  FOR  THE  RUN. 


USER-NAME 

SUBNAM 

OBJECT-FILE 


NAME  FROM  TDL  DESCRIPTION 
CONTROL  TRANSFERRED  TO  THIS  SUBR. 
OBJECT  CODE  FOR  USER  ROUTINE 


Figure  8-11 

Restructurer  Control  Cards  Required 
When  Running  with  User  Routines 


I 


*vJO>«iWW 


FILEDIT 

PRMFL  *R  * R » S»  MICHIGAN/RESTR ♦ RS 

FILE  R*»R0S*10L 
DATA  *C,,C0PY 

COPY  t kTDBSTA  LAST  SUBR 

INCLUDE 

LINK  UQUAL1 

ENTRY  UUQUA1 

SELECTD  NICHIOAN/UUQUA1 *0 

LINK  UC0NV1 

ENTRY  UUC0N1 

SELECTD  MICHIGAN/UUC0N1 »0 

LINK  UC0NU2 

ENTRY  UUC0N2 

SELECTD  M I CH IG AN/UUC0N2 ♦ 0 

ENDEDIT 

ENDCOPY 


Figure  8-12 

le  Control  Cards  to  Insert 
Routines  Into  Restructurer  R* 


9.0  RUNNING  THE  WRITER 


As  the  final  step  In  data  translation  It  Is  necessary  to  transfer  the 
record  Instances  from  the  target  database  produced  by  the  Restructurer  (the 
target  RIF)  which  Is  In  a relational  form  supported  by  ADBMS  to  the  user's 
target  IDS  database(s).  This  process  Is  known  as  writing  and  Is  performed 
by  the  Writer.  The  Writer's  sole  duty  Is  to  preserve  within  the  new  target 
IDS  database(s)  all  record  and  relation  Instances  represented  In  the  target 
RIF.  As  noted  previously  In  the  User  Manual,  the  Writer  will  produce  only 
target  IDS  databases  (not  ISP  or  sequential  files).  Up  to  five  different 
IDS  datlEases  can  be  written  from  a single  target  RIF  file. 

For  very  large  target  databases,  the  Writer  has  a useful  feature  which 
permits  partial  database  writes.  This  allows  the  user  to  split  the  execu- 
tion of  the  Writer  Into  different  machine-time  runs  In  case  computer  resources 
are  restricted.  For  example,  assume  a database  comprises  record  typ$s  A-Z, 
each  of  which  consists  of  2,000  Instances.  Further  assume  that  no  more 
than  two  hours  of  CPU  time  are  available  In  any  one  block.  Since  It  Is  not 
possible  to  write  out  52,000  records  In  less  than  two  hours,  the  partial 
database  write  feature  can  be  employed  to  permit  the  user  to  store  record 
types  A-F  on  one  run,  to  process  record  types  G-R  the  next  day,  and  finally, 
at  a later  date,  finish  the  writing  with  record  types  S-Z.  This  feature  Is 
described  In  complete  detail  In  Section  9.7. 

Before  executing  the  Writer  It  Is  necessary  that  all  Data  Translator 
steps  have  been  successfully  completed.  These  steps  are  summarized  below. 

1.  Write  source  and  target  IDS  NO  sections. 

2.  Write' and  analyze  the  source  and  target  extended  (with  level  61 
entries)  IDS  MD  sections.  Usethe  IDS  Analyzer  yielding  source 
and  target  SUDL  tables. 

3.  Ensure  that  the  Reader  produces  the  source  RIF  database  from  up 
to  five  source  IDS,  ISP  or  sequential  files  (or  combination 
thereof). 

4.  Write  and  analyze  Translation  Definition  Language  statements  dv 
using  the  TDL  Analyzer  to  produce  TDL  tables. 

5.  Execute  the  Restructurer  to  output  a target  RIF  which  contains 
up  to  five  target  IDS  database  records. 

The  user  additionally  must  create  via  FILSYS,  IDS  database  files  (subfiles, 
if  desired)  with  the  desired  IDS  attributes  (PAGESIZE,  INVENTORY,  etc.)  for 
each  of  the  target  IDS  databases  represented  In  the  target  RIF.  Care  must 
be  taken  to  ensure  that  the  database  size  Is  large  enough  or  the  Writer  will 
have  to  be  rerun. 

WARNING:  It  Is  absolutely  Imperative  that  the  description  of  the  physical 

layout  of  target  IDS  records  In  the  target  MD  section  and  the  extended 

target  MD  section  match  each  other  perfectly.  Specifically: 

1.  All  Items  In  the  IDS  MD  and  extended  IDS  MO  sections  must 
have  the  same  relative  order  and  length. 

2.  The  98  level  entries  must  appear  In  exactly  the  same  order 
In  both  target  IDS  MD  and  extended  IDS  MD  sections. 
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The  record  type  values  (e.g.  TYPE  IS  XXX)  must  be  Identical 
for  each  record  1h  both  target  IDS  MD  and  extended  IDS  NO 
sections. 

The  class  (e.g.  CALC,  PRIMARY,  SECONDARY)  of  a record  must 
be  the  same  In  both  target  IDS  HD  and  extended  IDS  MD 
sections. 


9.1  Detailed  Overview  of  Writer  Execution  . 

Executing  the  Writer  requires  five  activities  (with  activity  2 being 
deleted  If  the  second  through  n£!l  run  of  a partial  database  write  Is  being 
done).  These  are  denoted  as  follows. 


Activity 

1 UTILITY  copy  of  target  RIF  database  Into  a temporary  file. 

2 IDS  QUTI  execution  on  the  target  IDS  database  being  written. 
Note  that  this  activity  cannot  be  performed  If  partial 
database  writing  Is  In  progress.  If  three  executions  of 
the  Writer  are  required  to  produce  one  target  IDS  database, 
then  QUTI  should  be  called  only  for“tfie  first  run,  not  the 
second  or  third,  or  the  page  header  records  will  be  over- 
written. 


3 Compile  the  target  IDS  MD  section  Into  the  COBOL  portion 
of  the  Writer.  Because  the  Writer  uses  IDS  routines  to 
store  and  link  records,  object-time  version  of  the  target 
IDS  MD  section  must  be  available  at  execution  time.  Hence, 
the  user  Is  supplied  with  the  source  code  for  the  COBOL 
portion  of  the  Writer,  In  which  the  user  must  Insert  the 
target  IDS  MD  section,  compile,  and  then  execute  In  activity 
four.  See  Section  9.6  for  complete  details. 

4 Execute  the  Writer.  The  compiled  COBOL  program  from 
activity  three  calls  In  the  Writer  routines  supplied  on  an 
R*  file.  User  parameters  are  supplied  to  specify  which 
database  and  which  records  within  that  database  are  to  be 
written.  A permanent  record  Is  made  of  which  records 
were  written  If  a partial  database  write  Is  In  progress. 


0 

oi 


5 If  the  Writer  executed  with  no  fatal  errors,  the  temporary 

copy  of  the  target  RIF  (modified  during  activity  four)  Is 
redopled  back  Into  the  original  target  RIF  file.  Sub- 
sequent partial  database  writes  require  that  the  target 
RIF  file  (modified  for  any  given  run  1 by  activity  four) 
be  the  target  RIF  for  the  next  run  1 <•  1. 

The  Writer  execution  Is  Illustrated  In  Figure  9-1.  Each  component 
of  the  job  Is  summarized  below. 

Target  RIF  database  - Output  PRMFL  of  the  Restructures  It  Is  an  AD6MS 

database  containing  the  representations  of  up  to 
five  target  user  databases.  All  record  Instances 
of  a given  type  are  linked  together.  Relation  (set) 
Instances  are  maintained  In  a relational  way  by 
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Figure  9-1 

Executing  the  Writer 


UTILITY  COPY 


Temporary  Target  RIF 
database 


IDS  QUT1 


Target  IDS  database  - 


Part  I COBOL-Wrlter 
Main  Program 


Target  IDS  MD 


Part  2 COBOL-Wrlter 
Main  Program 


IDS  Translator 


Target  SDDL  Tables 


propagation  of  primary  keys.  Each  record  Instance  ' 
contains  a field  used  to  hold  the  IDS  reference 
code  of  Its  location  In  the  target  database. 

An  activity  utilizing  the  H-6000  UTILITY  function. 

In  activity  one,  a temporary  copy  of  the  RIF  Is 
made.  Activity  five  Is  a recopy  of  the  temporary 
RIF  Into  the  permanent  RIF. 

A temporary  (e.g.,$FILE)  version  of  the  target  RIF 
database.  During  activity  four,  the  IDS  reference 
codes  of  the  record  Instances  stored  are  placed  Into 
the  RIF  for  later  reference  during  either  the  current 
run  or  subsequent  runs.  If  activity  four  terminates 
with  no  fatal  errors,  this  file  Is  recopied  Into  the 
permanent  target  RIF. 

Invoked  with  a (PROGRAM  QUTI  card,  the  empty  target 
IDS  database  must  be  Initialized  with  page  header 
records.  If  partial  database  writing  Is  occurring, 
QUTI  should  be  used  only  for  the  first  Writer  execu- 
tion on  the  target  IDS  database. 

Created  as  either  one  file  or  many  subfiles  In  a 
previous  FILSYS  job,  the  target  IDS  database  Is  the 
file  that  the  user  desires  as  the  end  result  of  all 
data  translation.  If  subfiles  are  used,  each  must 
be  Identified  with  Its  own  $PRMFL  card  and  must  be 
Initialized  by  QUTI. 

The  IDENTIFICATION,  ENVIRONMENT,  and  DATA  Division 
Source  code  for  the  Writer  main  program.  The  user 
Inserts  the  target  IDS  MD  section  after  this  file 
(available  on  SYSGEN  tape). 

This  file  Is  used  as  the  base  for  the  target  extended 
IDS  W)  section  prepared  In  Section  3 of  the  User 
Manual.  All  attributes  of  each  record  such  as  PAGE- 
RANGE,  INTERVAL,  PLACE-NEAR,  etc.,  should  be  Identi- 
fied. The  file  Is  Inserted  between  the  two  parts 
of  the  COBOL-Wrlter  main  program.  The  first  card 
should  be  "MO  database-name". 

PROCEDURE  Division  of  the  Source  code  of  the  Writer 
Main  Program.  It  Is  placed  after  the  target  IDS  MD 
section  In  the  Input  deck  to  the  IDS  Translator  for 
activity  three. 

Invoked  with  a (IDS  card,  the  IDS  Translator  accepts 
as  Input  the  COBOL-Wrlter  Main  Program  and  the  target 
MD  section,  and  produces  a B*  file  containing  the 
object  version  of  the  Writer  Main  Program. 

Data  Translator's  Internal  tables  which  describe  the 
target  IDS  database  to  the  Writer.  These  were 
produced  from  the  target  extended  IDS  MD  section  by 
running  the  IDS  Analyzer  (see  Section  5). 


' -Mlifc'rn-  r •, 


Specification  to  the  Writer  to  Indicate  nrf»1ch  of  the 
databases  (of  five  possible)  In  the  target  RIF  Is 
to  be  written  Into  an  IOS  database.  Directives 
concerning  total  or  partial  database  writing  are 
supplied. 

If  partial  database  writes  are  being  used.  It  Is 
necessary  to  store  Information  concerning  which  records 
were  written  on  each  partial  execution.  This  Informa- 
tion Is  maintained  In  a file  which  Is  sequential 
(two  links  Is  sufficient).  There  must  be  one  "between 
runs  save  file"  per  target  database. 

The  Writer  R*  file  (available  on  the  SYSGEK  tape). 


Run-time  parameters 


Between  runs  save 
file 


Writer  routines 


9.2  Explanation  of  Processing  Flow 

This  section  sketches  a brief  overview  of  the  algorithms,  an< 

outputs  of  the  entire  Writer  execution.  Note  that  at  minimum,  the  Wrltei 
must  be  executed  once  per  target  database  to  be  written.  Additionally,  < 
database  write  can  be  separated  Into  partial  database  writes  If  computer 
resources  are  limited. 

9.2.1  Activity  1 - Utility  Copy  of  Target  RIF 
Inputs 

1.  PRMFL  for  target  RIF  database 
Algorithm 

A SFUTIL  fllecode,  fllecode,  RC0PY/1F/  directive  Is  supplied  to 
UTILITY . 

9.2.2  Activity  2 - Initialize  IDS  database 
Inputs 

1.  An  empty  IOS  database  represented 
by  either 

a)  1 SPRMFL 

b)  multiple  SPRMFLs  If  subfiles 
are  used 

2.  Directives  to  Initialize  the  IDS 
database 

Algorithm 

Each  subfile  must  have  Its  own  IDS  INITIAL  directive  for  Its  page-range 
Note  that  this  activity  should  not  be  Included  Writer 


Outputs 

1.  FILE  for  RIF  database 


Outputs 

1.  An  Initialized  IDS  database 


Outputs 

A 8*  file  containing  an 
object  COBOL- IDS  program 
with  the  target  IDS  database 
represented  by  the  common 
area  .IDS.. 


Source  code  for  pert  1 of  the 
Writer  Mein  program 

User's  target  I OS  MO  section 

Source  code  for  part  2 of  the  Writer 
Mein  program 

Algorithm 

# s1in?le  COBOL- IDS  compile  activity  Is  performed 


No  permanent  object 


file  Is  required. 

9-2-*  Activity  4 - Execute  the  Writer 
Inputs 

1.  Run-time  parameter  file 

2.  Target  SDDL  tables 

3.  Between  runs  save  file 

4.  Target  RIF  file  (temporary  copy) 


Outputs 

Execution  report 

Error  report 

Target  IDS  database 

Undated  Target  RIF  file 

Updated  between  runs  save 
file 


Algorithm 


Activity  4 can  be  viewed  in  the  following  two  ways, 
a)  Multiple  and  partial  database  writing. 

6 IDSCf11e°f  transferr1ng  records  frotn  target  RIF  to  the  target 

Multiple  and  Partial  Database  Writing 

databafe  t0Vflr1te  is  determined  by  which  values 
placed  on  the  run-time  parameter  cards.  The  user  must  specify  the 


Identic  tar- 
get database 
to  be  written 


Enter  MN0" 
on 

runtime  file 


Enter  “YES 


Attach  FRHFL 
for  between 
runs  save 
file 


Enter  "PART" 
on 

runtime  file 


Enter  “ALL 


Enter  records 
to  be  written 
on  runtime 
file 


Attach  $FILE 
for  unused 
between  runs 
file 


TIm  Writer  algorithm  Is  simple  to  understand.  Basically,  the  process 
Is  driven  by  the  SDOL  tables.  All  Instances  of  a record  type  are  written 
to  the  I OS  file  before  any  other  record  type  Is  written.  Briefly  then, 

I.  For  all  masteries*1  record  types 

1.  Store  every  Instance  of  the  record  type. 

2.  Record  location  of  each  Instance  within  target  IDS 
file  back  In  the  target  RIF  file. 

II.  For  all  detail2  record  types  whose  masters  have  been  previously 
stored 

1 . Store  every  Instance  of  the  record  type  by 

a)  Setting  current  the  master  record  Instances  by 
modifying  the  IOS  chain  tables. 

b)  Storing  detail  record  Instances  letting  IOS 
do  all  the  linking. 

For  example,  observe  Figure  9-3,  a sample  IOS  schema.  By  definition, 
record  types  A,  B and  C are  the  only  masterless  record  types  of  the  data- 
base. They  will  be  written  out  before  their  detail  types.  Records  0,  E, 
F and  6 are  detail  record  types.'  The  constraints  on  their  storage  areas 
follows. 

Record  Types  that  must  have 

Record  Types  been  previously  stored 


The  user  should  observe  the  following  rule  when  constructing  the  run* 
time  parameter  file. 

If  partial  database  writes  are  In  progress,  then  the  record 
types  selected  for  a given  partial  write  are  constrained  according 
to  the  Mrlter  algorithm.  No  record  typ®  may  be  written  out  on  a run 
unless  all  of  Its  master  record  typos  were  previously  written  on 
prior  runs  or  will  be  written  on  the  current  run.  From  a diagrammatic 
view,  the  target  IDS  database  must  be  written  In  a top  down  fashion, 
starting  with  the  masterless  records.  Figure  9-4  shows  sample  correct 
and  Incorrect  partial  database  write  sequences.  Remember  that  the  QUTI 
activity  Is  used  only  for  partial  database  write  #1. 


1 A masterless  record  type  Is  defined  to  be  an  IDS  record  that  Is  either 

a)  a CHAIN  DETAIL  of  zero  chains. 

b)  a CHAIN  OETAIL  of  only  the  CALC  CHAIN. 

2 A detail  record  typo  Is  defined  to  be  an  IDS  record  that  Is  a 98  CHAIN 
DETAIL  of  one  or  more  non-CALC  chains . 


i4aajajte<rit&wiSii awfea 


PRIMARY 


Figure  9-3 
Sample  IDS  Schema 


Correct  Correct  Incorrect 


D Is  & detail  of  C 


stored) 


Partial  Run  #1 
Partial  Run  #2 


which  has  not 


6 (records  E and  F 
are  not  being  written 
this  run  and  were  not 
written  on  run  #1) 


Partial  Run  #3 
Partial  Run  #4 


Figure  9-4 

Partial  Oatabase  Write  Sequences 


9.2.5  Processing  Limitations  on  Writer 

Due  to  memory  constraints  In  the  development  of  the  Data  Translator, 
several  restrictions  are  placed  upon  the  user  when  running  the  Writer. 

They  are  listed  below  with  suggested  action  to  circumvent  them. 

1.  Number  of  target  record  types  must  be  less  than  or  equal  to  75. 

There  Is  no  way  to  overcome  this  restriction  unless  the 
Writer  R*  files  are  recompiled  with  new  dimensions. 

2.  A record  may  not  be  a detail  of  more  than  ten  (10)  chains. 

See  #1. 

3.  A record  may  not  have  more  than  sixty  (60)  fields. 

If  some  fields  (contiguous)  are  not  being  used  for  a particular 
Restructuring  operation  (e.g.  primary  key,  qualifier  Item, 
etc),  they  can  be  grouped  together  Into  one  large  Item.  Note 
that  this  grouping  must  be  reflected  In  the  target  SDDL  tables 
and  hence  the  target  IDS  extended  MD  section. 

4.  A record  may  not  be  longer  than  640  words. 

It  Is  Impossible  to  overcome  this  limitation;  do  not  design 
target  records  larger  than  640  words. 

5.  An  Item  may  not  be  longer  than  255  characters. 

This  Is  an  ADBHS  restriction.  To  avoid  It,  subdivide  the  "long" 
Item  Into  smaller  (<  255)  Items.  Subject  to  restriction  #3 
above. 

6.  Contained- In-repeating  groups,  match-key  and  phantom  pointer  relations 
cannot  be  produced  In  the  target  database. 

None  of  the  above  constructs  should  be  In  the  target  database. 
Such  features  are  not  under  the  control  of  IDS  and  are  therefore 
undesirable. 

7.  The  number  of  masterless  record  typos  may  not  exceed  fifty  (50). 

Short  of  redesigning  the  target  database,  there  Is  no  way  to 
avoid  this  limitation  except  to  recompile  the  Writer  R*  file. 

lete  JCL  to  Execute  the  Writers 

Figure  9-5  Is  the  complete  listing  of  control  cards  necessary  to 
execute  the  Writer  In  one  job.  The  sequence  of  control  cards  Is  avail- 
able on  the  SYSGEN  tape  and  must  be  modified  according  to  trftlch  files  the 
user  Is  supplying  for  a given  run.  User  changes  to  the  control  card 
sequences  are  listed  below  by  line  number. 


Description 

The  PRMFL  for  the  target  RIF  database 
produced  by  the  Restructurer 

The  size  of  the  target  RIF  In  random 
LINKS.  Note  that  the  target  RIF  size 
wist  be  a Multiple  of  12  LLINKS  or 
activity  5 will  abnormally  teralnate 
within  UTILITY. 

Target  IDS  database  file.  It  must  have 
fllecode  of  Any  subfiles  must  have 
fllecojtes  In  sequence  from  Xl,X2...Xn. 

IDS  INITIAL  directives  must  be  supplied 
for  each  subfile  present.  The  entire 
range  of  pages  must  be  Initialized. 

Source  code  file  from  SYSGEN  tape  of  part 

1 of  the  COBOL-Wrlter  Main  program.  Must 
be  an  ASCII  file. 

ASCII  file  containing  a legal  target  IDS 
MO  section  that  was  used  as  a base  for 
the  extended  target  MO  section  processed 
subsequently  by  the  IDS  Analyzer. 

Source  code  file  from  SYSGEN  tape  of  part 

2 of  the  COBOL-Wrlter  Main  program.  Must 
be  an  ASCII  file. 

The  R*  file  of  the  Writer  available  on 
the  SYSGEN  tape. 


0420-0430 


0440-0510 


0010 
0020 
0030 
0040 
0060 
0070 
0080 
0090 
0100 
0110 
0120 
0130 
0140 
0150 
0160 
0170 
0180 
0190 
0200 
0210 
0220 
0230 
0240 
‘ 0250 
0260 
0270 
0280 
0290 
0300 
0310 
0320 
0330 
0340 
0350 
0360 
0370 
0380 
0390 
0400 
0410 
0420 
0430 
0440 
0450 
0460 
0470 
0480 
0490 
0500 
0510 
0520 
0530 
0540 
0550 
0560 
0570 
0580 
0590 
0600 
0610 
0620 


IDENT 

NOTE  *************** *****************4****************** 
NOTE  * EXECUTE  THE  WRITER  JCL  * 

NOTE  * * 

NOTE  * UTILITY  COPY  OF  TARGET  RIF  INTO  TEMP*  FILE  * 

note  *************************************************** 

UTILITY 

FUTIL  A1»A2»RC0PY/1F/ 

PRMFL  A1»R»R»TARGET  RIF  FILE 
FILE  A2r X18»SIZE  OF  TARGET  RIF  IN  LINKS 
NOTE  *************************************************** 
NOTE  * IF  THIS  IS  THE  FIRST  RUN  ON  A TARGET  * 

NOTE  * DATABASE r THEN  INCLUDE  THIS  ACTIVITY » * 

NOTE  * ELSE  SKIP  DOWN  TO  THE  COMPILATION  * 

NOTE  * * 

NOTE  * INITIALIZE  TARGET  IDS  DATABASE  * 

NOTE  *************************************************** 
PROGRAM  OUT I 

PRMFL  XI 'REC'Rt TARGET  IDS  DATABASE 
DATA  I* 

INITIAL  PAGE  RANGE  OF  TARGET  DATABASE 

NOTE  *************************************************** 
NOTE  * COMPILE  THE  MD  SECTION  INTO  THE  WRITER  * 

NOTE  *************************************************** 
IDS  NDECK 

8ELECTA  COBOL -WR I TER  SOURCE  CODE  PT.  1 
SELECTA  TARGET  IDS  MD  SECTION 
SELECTA  COBOL -WRITER  SOURCE  CODE  PT«  2 

NOTE  *************************************************** 
NOTE  * EXECUTE  THE  WRITER  * 

NOTE  *************************************************** 
EXECUTE  NREST 


$ PRMFL  R*rR»S'WRITER  R* 

* FILE  H*'H1R»20R 

* LIMITS  XX '52Kr-2K' 10000  USE  APPROP*  TIME  REQMNTS 

* FILE  02'X1S  TARGET  RIF 

* REMOTE  06  EXECUTION  REPORT 

$ REMOTE  07  ERROR  REPORT 

$ PRMFL  08rW»RrTARGET  SDDL  TABLES 

* DATA  15  USER  INPUT  PARAMETERS 

DATABASE  NAME 

SPECIFICATION  OF  REC0RD8  TO  BE  WRITTEN 

* NOTE  

* NOTE  - INCLUDE  EITHER- 

* NOTE  - * FILE  16rX2R'2L  IF  ALL  RECORDS  ARE  WRITTEN 

* NOTE  - THIS  RUN 

* NOTE  ~ OR- 

* NOTE  - 4 PRMFL  16»W'S» BETWEEN  RUNS  SAVE  FILE  IF  ONLY 

* NOTE  - PARTIAL  DATABASE  WRITE  IS  MADE 


USE  APPROP ♦ TIME  REQMNTS 
TARGET  RIF 
EXECUTION  REPORT 
ERROR  REPORT 


08rW»RtTARGET  SDDL  TABLES 


USER  INPUT  PARAMETERS 


NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

PRMFL 

PRMFL 

NOTE 

NOTE 

NOTE 

NOTE 

IF 

UTILITY 

FUTIL 

FILE 

PRMFL 


i 


XI fRECrRr TARGET  IDS  DATABASE 
TR'R'R* TRANSLATOR  LIBRARY 

*************************************************** 

* GO  TO  ENDJOB  IF  UNSUCCESSFUL  WRITER  RUN 

* ELSE  COPY  UPDATED  RIF  BACK  TO  PRMFL  * 
*************************************************** 
/35» ENDJOB 


Al»A2rRC0PY/lF/ 

AlrXIR 

A2»W»R»TARGET  RIF  FILE 


Description 


0520  Target  IOS  database,'  same  as  In  line 

0200.  XI  Is  the  required  fllecode.  If 
subfiles  are  used  then  the  fllecodes  must 
be  In  sequence  from  XI,  X2,  X3  ...  Xn. 

«30  Object  time  random  library  of  Data  Trans- 

lator routines  available  from  SYS6EN  tape 
Must  be  attached  to  fllecode. TR. 

0520  Target  RIF  file  name,  same  as  line  0100. 

Note  that  lines  0190  through  0220  are  not  Included  for  partial  data- 
base writes  that  are  the  second  or  subsequent  runs  on  the  given  IDS  data- 
base file. 


IDENT 

note  »★»»»»»»»»»»»*»***»♦♦»»*♦♦* ******  ** ************* 

NOTE  * EXECUTE  THE  WRITER  JCL 

NOTE  * 

NOTE  * UTILITY  COPY  OF  TARGET  RIF  INTO  TEMP.  FILE 
NOTE  ★ ** **  **  **************** ** ** ********  ************* 

UTILITY 

FUTIL  A1 , A2.RCOPY/1 F/ 

PRMFL  A I, R, R, TARGET  RIF  FILE 

FILE  A2.X I S. SIZE  OF  TARGET  RIF  IN  LINKS 

nd*  LUD  Description 


PRMFL  of  target  RIF  produced  by 
the  Restructurer 

Temporary  file  of  size  equivalent 
to  the  target  RIF.  Must  be  a 
random  file. 


Output  Is  normal  UTILITY  output  and  hence  Is  not  shown 


RCOPYD  1 
;.  Correct 


The  user  should  check  report  code  53  to  see  If  the  message  "l 
FILES"  Is  printed.  Any  other  result  Is  an  error  In  control  cards 
If  necessary  and  rerun. 


Activity  2 - Initialize  Target  IDS  Database 


NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

PROGRAM 

PRMFL 

DATA 

INITIAL 


♦♦**♦*♦♦*<  »♦»****♦♦♦♦♦**♦♦**♦»♦  **********  ********* 
+ IF  THIS  IS  THE  FIRST  RUN  ON  A TARGET 

* DATABASE.  THEN  INCLUDE  THIS  ACTIVITY, 

* ELSE  SKIP  DOWN  TO  THE  COMPILATION 

* 

* INITIALIZE  TARGET  IDS  DATABASE  * 

*************************************************** 
OUT  I 

XI ,REC,R. TARGET  IDS  DATABASE 
r* 

PAGE  RANGE  OF  TARGET  DATABASE 


Fllecode 

XI 


LUD 


Description 

Target  IDS  database  file.  If 
subfiles  are  being  used  then 
several  fllecodes  Xl,Xw,...Xn  are 
required  for  each  PRMFL 

Directives  to  Initialize  each  IDS 
subfile  page  range.  Only  one 
INITIAL  directive  Is  required  If 
subfiles  are  not  present. 


User  Parameters 


Standard  IDS  QUTI  output.  It  is  therefore  not  presented  here. 
Possible  Errors 

1.  Incorrect  directive  syntax,  e.g.  column  rules  not  obeyed,  "INITIAL 
spelled  wrong,  etc. 

Action:  Correct  directive  and  rerun  Writer. 

page  range  specified;  the  INITIAL  directive  must  specify 
numbers  of  the  IDS  file  (or  subfile)  as  It  was  created. 

Correct  dlrectlve(s)  and  rerun  Writer. 

lie  COBOL- Writer  Main  Program 


2.  Incorrect 
the  page  i 

Action:  i 


9.6  Activity  3 


NOTE  * COMPILE  THE  MD  SECTION  INTO  THE  WRITER 

NOTE  ***+  ***********++*******+*  ************++** 

IDS  NDECK 

SELECTA  COBOL-WRITER  SOURCE  CODE  PT.  1 
SELECTA  TARGET  IDS  MD  SECTION 
SELECTA  COBOL-WRITER  SOURCE  CODE  PT . 2 


Filecode 


Description 

Resultant  file  from  $SELECTA-ing 
the  COBOL-Writer  Main  program  part 
I»  target  IDS  MD  section  and  COBOL- 
Writer  Main  program  part  II  in 
that  sequence.  Used  as  source  IDS 
program  input  to  the  IDS  Translator. 

A $ FILE  *3  may  be  required  for  large 
databases . 


User  Parameters 
None 


Examples  of  Output 

Standard  compilation  output  from  IDS  then  COBOL.  It  is  therefore 
not  presented  here. 

Possible  Errors 

1.  IDS  errors  - any  possible  errors  that  IDS  can  detect  could  appear. 
However,  since  the  target  MD  section  was  used  as  a base  for  the  target 
extended  MD  section  (and  hence  target  SDDL  tables)  any  errors  appearing 
this  late  in  the  sequence  of  translation  could  cause  rerunning  of  the 
IDS  Analyzer  on  the  target,  TDL  Analyzer  and  Restructures  The  user 
should  have  noted  in  Section  3 the  requirement  that  the  base  for  the 
extended  MD  section  must  be  a legal  MD  section  with  no  errors.  If 

all  translation  steps  have  been  followed,  especially  the  rules  in 
Section  3,  then  no  errors  should  occur  in  activity  three  of  the  Writer. 

Action:  If  any  of  the  following  errors  occur,  and  the  same  error  is 
present  (but  undetected)  in  the  target  IDS  extended  (with  level  61s) 

MD  section,  then  the  user  must  backtrack  and  recreate  the  target  SDDL 
tables  (after  fixing  the  target  MD  and  extended  MD  sections)  and  hence 
the  TDL  Analyzer  and  Restructurer  must  be  rerun. 

CHAIN  errors  (Missing  masters,  details,  loops) 

RECORD  errors  (Invalid  TYPE,  Incorrect  PRIMARY  or  CALC  speci- 
catlon) 

The  Inordinately  high  cost  of  recovery  from  these  errors  makes  their 
avoidance  essential.  Carefully  following  the  rules  presented  In 
Section  3 and  the  IDS  Programmers  Guide  Is  necessary. 

2.  COBOL  errors  - will  be  of  the  following  two  types: 

a)  Errors  which  use  a Writer  reserved  word  as  a data  Item  In 
the  target  MD  section.  This  error  cannot  be  detected  by 
the  IDS  Analyzer. 

b)  COBOL  Data  Division  errors;  invalid  PICTURES,  misspelled 
keywords,  missing  punctuation  or  Incorrect  SIZE  clauses. 

Not  all  of  these  errors  could  have  been  previously  detected 
unless  the  user  had  followed  the  advice  of  Section  3 and 
compiled  the  target  IDS  MD  section  Into  a dummy  COBOL 
program  to  detect  any  COBOL  ERRORS. 
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Action:  If  the  user  chose  a Writer  reserved  word  as  a data  Item 
name,  change  the  name  to  an  unused  one  and  rerun  the  Writer.  If  a 
COBOL  error  occurred  In  the  Data  Division  and  that  error  Is  present 
In  the  extended  target  IDS  MD  section,  then  the  target  SDDL  tables 
must  be  recreated,  and  the  TDL  Analyzer  and  Restructurer  rerun. 
Again  note  the  high  cost  of  this  error  and  the  emphasis  on  avoidance 

9.7  Activity  4 - Execute  the  Writer 


$ NOTE  *************************************************** 

% NOTE  * EXECUTE  THE  WRITER  * 

* NOTE  *************************************************** 

* EXECUTE  NREST 

* PRMFL  R*»R»S» WRITER  R* 

% FILE  H*>H1R»20R 

* LIMITS  XX »52Kf-2K» lOOOO  USE  APPROP.  TIME  REQMNTS 

* FILE  02»X1S  TARGET  RIF 

$ REMOTE  06  EXECUTION  REPORT 

$ REMOTE  07  ERROR  REPORT 

$ PRMFL  08 >WfR> TARGET  SDDL  TABLES 

* DATA  15  USER  INPUT  PARAMETERS 

DATABASE  NAME 

SPECIFICATION  OF  RECORDS  TO  BE  WRITTEN 


NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

PRMFL 

PRMFL 


INCLUDE  EITHER 
S FILE  16? X2R*2L 


IF  ALL  RECORDS  ARE  WRITTEN 
THIS  RUN 


* PRMFL  16rWf SrBETWEEN  RUNS  SAVE  FILE  IF  ONLY 
PARTIAL  DATABASE  WRITE  IS  MADE 


XI »REC»R» TARGET  IDS  DATABASE 
TR f R » R f TRANSLATOR  LIBRARY 


Fllecode 
B*  (not  shown) 


Description 

Output  from  COBOL-IDS  compile 
from  activity  three. 

Writer  R*  file  from  SYSGEN  tape 


Temporary  random  file  for  Loader 
H*  file.  Must  be  supplied  so 
entry  can  be  made  In  PAT. 

Temporary  RIF  database  from  activity 
one. 


Description 


Fllecode 


Writer  Execution  Report 

Writer  error  messages 

PRMFL  for  the  target  SDDL  tables 

Runtime  parameter  file  Is  Inserted 
following  the  $DATA  15  card.  See 
below  for  format. 

Between  runs  save  file.  If  a 
temporary  file  Is  being  used  (e.g. 
a total  database  write),  the  X2R 
Is  the  LUD;  otherwise  a PRMFL  Is 
Included  here. 

Target  IDS  database  file.  If 
subfiles  are  used  they  must  have 
fllecodes  XI,  X2,  X3. ..  assigned 
In  sequence. 

Translator  library  of  object 
routines. 


User  Parameters 

The  user  must  supply  run-time  parameters  guiding  the  Writer  according 
to  the  following  rules. 

CARD  1 database-name 

CARD  2 first-run  total /partial 

CARDS  3-N  record-name 


database-name  must  be  a legal  database  name  of  one  of  the  five 
possible  databases  present  In  the  target  RIF.  It  must  correspond 
to  the  database-name  supplied  during  IDS  Analyzer  execution 
yielding  the  target  SDOL  tables.  See  Section  5.6  In  which  the 
IDS  Analyzer  run-time  parameter  file  was  created  for  the  target 
database  descrlptlon(s). 

first-run  Is  either 

YES  In  columns  1-3  Indicates  that  this  Is  the  first  Writer 
execution  to  output  this  database. 


NO  In  columns  1-2  Indicates  that  this  Is  a second  or  subse- 
quent run  In  writing  this  database.  "NO"  Is  only 
applicable  for  partial  database  writes.  If  NO  Is  specified 
a permanent  between  runs  save  file  must  be  supplied  on 
fllecode  16. 

| ’•  f i < % 'J  jf^fT  1 "*{,,■  v Sj.1 ’»*  ft  k +*  / & . ; ; "V  ■■  ^ * {>  ; Av.i  Si  Y jrAf  1 

total /partial  Is  either 

ALL  In  columns  7-9  Indicates  that  all  records  for  database 
name  are  to  be  written  on  this  run.  "ALL"  cannot  be 
specified  If  "NO"  was  used  for  first-run. 
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PART  In  columns  7-10  Indicates  that  a partial  database 
write  Is  being  made;  the  records  to  be  written  will  be 
Identified  on  cards  3 through  n. 

4.  record-name  Is  a legitimate  IDS  01  record  name  from  the  target 
MO  section.  For  each  record  type  to  be  written,  one  record 
name  per  card  must  be  supplied.  The  record  name  must  start  In 
column  1. 

Example  Use  of  Run-time  Parameter  File 

Let  Figure  9-6  be  the  schema  for  the  STATES  database.  Because  It 
Is  desired  that  this  database  be  written  out  In  two  runs,  partial  data- 
base write  Is  required.  Figure  9-7  shows  the  run-time  parameter  files 
required  for  runs  1 and  2.  The  file  "MICHIGAN/PPS.SF"  Is  the  between  runs 
save  file  for  the  STATES  database. 


The  Writer  output  can  be  divided  Into  two  sections:  the  execution 
report  and  the  error  message  report.  An  explanation  of  the  execution 
report  Is  provided  below;  error  messages  are  summarized  In  Appendix  E. 

Writer  execution  Is  subdivided  Into  three  units  within  the  execution 
report. 

INITIALIZATION  (Figure  9-8) 

A summary  of  the  user's  run-time  parameter  file  Is  placed  at  the  top 
of  the  execution  report.  Results  of  any  previous  partial  database  writes 
(not  shown  In  Figure  9-8)  are  also  summarized.  Records  to  be  written  on 
the  current  run  are  listed  with  the  following  attributes. 


IDS  RECORD  NAME 


The  01  record  name  from  the  target  SDDL  tables 
of  the  record  to  be  written. 


IDS  RECORD  TYPE  - IDS's  record  type  value  from  1-999  that  Identifies 

the  record  type. 


RIF  NAME 


AODR.  OF  RD 


- The  ADBMS  name  that  corresponds  to  the  full  IDS 
record  name  of  the  target  RIF  record. 

- Run  time  address  of  the  Record  Definition  record 
of  the  IDS  Definition  Structure  produced  by 
compiling  the  target  IDS  MO  section. 


MASTERLESS  Store  (Figure  9-9) 

As  noted  In  Section  9.2,  the  Writer  algorithm  stores  Masterless 
record  types  first.  In  Figure  9-9,  the  CONGRESS  and  STATES- IN-UNION  records 
are  the  only  masterless  record  types  for  the  NEW-PRESIDENTIAL  database. 

TOTAL  # INSTANCES  STORED  Is,  to  the  best  of  the  Writer's  knowledge,  the 
count  of  the  number  of  record  Instances  successfully  stored  Into  the  target. 
Its  value  should  be  compared  to  the  output  of  the  Restructurer  to  determine 
whether  Instances  were  lost  In  the  transfer  between  the  target  RIF  data- 
base and  the  target  IDS  file.  If  there  Is  a difference.  It  should  be 
accounted  for  In  the  Writer  error  report. 


. . . 


STATES-S 


HAS-NATIVE 
PERSON / 


HAS-LAR6E-CITIES 


CITIES 


PRESIDENT-S 


PERSONAL-DATA 


OCCUP-MARR 


Figure  9-6 

Sample  Target  Schema  - STATES  database 


USER  INPUT  PARAMETERS 


NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

NOTE 

PRMFL 


INCLUDE  EITHER-  _ 

$ FILE  16,X2R,2L  IF  ALL  RECORDS  ARE  WRITTEN 

THIS  RUN 

OR- 

$ PRMFL  1 6, W,S, BETWEEN  RUNS  SAVE  FILE  IF  ONLY 
PARTIAL  DATABASE  WRITE  IS  MADE 


IdfW,  S*MICHIGAN/PPS'.SF 


USER  INPUT  PARAMETERS 


$ DATA  15 

STATES 
NO  PART 

PRESIDENT-S 
OCCUP-MARR 
$ NOTE 

$ NOTE 

f NOTE  - 

$ NOTE 

$ NOTE 

t NOTE 

• NOTE 

9 NOTE  — 

$ PRMFL  1dfW,S,MlCHIOAN/PPS.SF 


INCLUDE  EITHER-  

9 FILE  16«X2R«2L  IF  ALL  RECORDS  ARE  WRITTEN 

THIS  RUN 

OR- 

t PRMFL  l6*MvSf BETWEEN  RUNS  SAVE  FILE  IF  ONLY 
PARTIAL  DATABASE  WRITE  IS  MADE 


Figure  9-7 

Run-time  parameter  Files  for 
Partial  Data  Write  of  the  STATES  Database 


**MRITER  INVOKED** 


|§s?  tp 


LJ 


itfjilh  ‘ Ifarttf  rH  i ilii  tiff  j 


DETAIL  Stort  (Figure  9-10) 

Once  all  tha  master! ess  records  have  been  stored,  the  Writer  stores 
the  detail  records.  Each  detail  record  has  attributes  that  are  printed 
for  Informational  purposes.  These  Include: 

DETAIL  OF  CHAIN  - The  IOS  chain  name(s)  of  which  the  record  Is 

a detail. 

SET  NAME  - The  ADBMS  set  name  within  the  target  RIF  which 

-;>  corresponds  to  the  chain  name. 

OWNER  RECORD  - The  A08MS  record  name  which  Is  the  owner  record 

of  the  SET  NAME.  The  detail  record  being  stored 
Is  a member  of  SET  NAME. 

NXT  - Displacement  within  the  IDS  record  (In  characters) 

of  the  Chain  next  pointer  for  the  chain  name  on 
the  same  line. 

PRIOR  - Same  as  NXT  except  for  the  Chain  prior  pointer. 

Zero  If  chain  Is  not  LINKED  PRIOR. 

ADDR.  OF  MO.  - Run-time  address  within  the  .IDS.,  coranon  block 

of  the  Master  Definition  record  for  the  chain  on 
the  same  line  of  output. 

As  before,  the  user  should  verify  that  no  record  Instances  are  un- 
accounted for  between  the  target  RIF  file  and  the  target  IDS  database. 


Figure  9-11  presents  an  example  of  two  Writer  errors.  A complete 
list  of  all  Writer  errors,  their  causes  and  appropriate  actions  Is  avail- 
able In  Appendix  E. 

Note:  If  an  error  occurs  In  a Writer  execution  that  Is  serious  enough 
to  warrant  rerunning  the  Writer,  and  If  the  following  two  condi- 
tions hath  hold,  then  special  action  Is  necessary: 

a)  The  execution  of  the  Writer  with  the  error  was  not  the  first 
run  of  a partial  database  write  sequence. 

b)  At  least  one  Instance  of  the  erroneous  record  type  was  success- 
fully stored  Into  the  IDS  database. 

The  special  action  Is  simply  to  start  all  over  again  with  the  first 
run  of  the  partial  database  write  sequence  (and  Renee,  Including  the 
QUTI  activity); otherwise,  multiple  copies  of  the  same  record  Instance 
will  end  up  In  the  target  database. 


Figure  9-11 

Sanple  Writer  Error  Output 


Description 

Import ry  copy  of  RIF  crottotf  In 
activity  ono  and  updated  In  activity 
four. 

Permanent  RIF  flit  for  target  data- 
bate(s).  Sam  file  as  In  activity 


Standard  UTILITY  output , hence  not  shorn 


Activity  four  of  the  Writer  will  turn  on  bit  35  of  the  PSW  If  no 
fatal  Writer  errors  occurred.  Otherwise,  the  $IF  card  will  cause  activity 
five  to  be  skipped  as  there  Is  no  longer  a need  to  UTILITY  copy. 

Any  errors  In  activity  five  would  be  due  to  control  card  errors 
which  unfortunately  would  necessitate  rerunning  the  Writer  If  (and  only 
when)  the  Writer  run  represents  a partial  database  write  other  than  the 


10.0  VALIDATING  OUTPUT 

TIM  purpose  of  validating  the  target  database  Is  to  assure  the  user 
thdt  the  transformation  specified  by  the  TOL  produced  the  desired  results. 
Deviations  are  possible  because  of  the  presence  of  semantic  data  In  the 
source  database  or  possible  omissions  In  specifying  desired  target  groups 
and  relations.  Improper  access  path  designation  In  the  TDL  may  produce 
target  relations  as  specified  but  cause  the  omission  of  some  desired  target 
Instances. 

To  ensure  that  a transformation  has  been  successful  It  is  necessary 
to  exhaustively  check  both  relationships  and  Instances  present  In  the 
target  database.  Three  methods  are  suggested  for  application  In  varying 
situations. 


10.1  COBOL  Application  Programs 


For  databases  in  a medlum-to-very-large  range  (from  20  pages  up)* 
application  programs  undoubtedly  provide  the  best  exhaustive  check  of  the 
database  and  can  be  formatted  for  rapid  visual  verification.  Programming 
In  COBOL  is  the  preferred  method  of  validation  If  the  resulting  code  has 
some  recurring  value  in  use  to  justify  the  Implementation  time. 

In  the  case  of  a single  use,  however,  WWDMS  provides  a shortcut  that 
Is  equally  effective  and  less  time  consuming. 


10.2  IDS  Database  Pimps 

For  small  databases  (less  than  20  pages)  a reasonable  alternative  to 
programming  for  verification  Is  to  use  the  IDS  dump  utility  and  check  the 
database  manually.  Minimal  knowledge  of  IDS  storage  structures  and 
substantial  patience  are  the  only  requirements. 

Some  valuable  side  effects  of  this  method  are  that  the  database 
designer  sees  the  physical  result  of  page  ranging  and  Input  ordering;  the 
space  and  overhead  Involved  with  set  relationships;  and  the  physical  size 
of  records. 


10.3  WMOHS  Queries 

The  UMOMS  environment  allows  a user  to  retrieve  and  format  Information 
from  an  IDS  database  in  a shorthand  manner.  Without  going  Into  the  details 
of  the  query  system  Its  use  allows  access  to  any  information  In  the  database 
via  almost  any  route  available  to  a COBOL  application  program. 

The  user  writes  an  Application  Definition  File  (ADF)  which  specifies 
access  paths  through  the  database.  After  It  has  been  processed  with  a 
Dictionary  (the  COBOL  MD  section)  the  paths  may  be  nested  to  produce 
exhaustive  dumps  of  the  chained  relations.  Output  formatting  Is  as  flexible 
as  COBOL  programs  In  a simple  command  (LINE). 


1 Present WWDMS-T2  does  not  allow  the  "heading"  of  nested  chains 


r. 
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For  purposes  of  exhaustive  checks  It  Is  necessary  to  write  the  AOF 
such  that  all  paths  aaanatlng  from  a given  SYSTEM  entry  point  be  nested  to 

""  ' - - * * - * In  thf*  ~ 
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to  penal  t slaple  cross-checking  of  the  output  lists. 
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11.0  EXAMPLE  TRANSLATION  # 

This  section  shoes  by  example,  the  steps  which  a user  must  perform 
for  each  function  of  tho  Data  Translator.  The  example  used  Is  the 
restructuring  of  the  "NEW-PRESIDENTIAL"  database  Into  a "STATES"  database. 
Bachman  diagrams  for  oach  are  shown  In  Figure  11-1. 

The  user's  first  step  Is  usually  augmenting  her/his  IDS  HD  section 
for  the  source  database  with  61  level  entries.  This  process  Is  described 
In  Section  3.0.  The  augmented  MD  section  for  the  NEW-PRESIDENTIAL  database 
Is  shown  In  Figure  11-2.  Next,  the  user  should  create  an  empty  source  SDDL 
database  file  and  run  the  IDS  Analyzer  with  the  augmented  IDS  MD  section 
as  Input.  Setting  up  the  JCL  for  the  IDS  Analyzer  is  described  in  Section 
5.0.  The  JCL  for  this  example  Is  shown  In  Figure  11-3. 

The  user  should  thon  perform  a similar  set  of  steps  for  the  target^ 
database.  The  61  level  augmented  IDS  MD  section  Is  shown  In  Figure  11-4 

while  Figure  11-5  Is  the  IOS  Analyzer  JCL.  . „ Tni  -.kw 

The  next  twm>  stops,  running  the  Reader  and  producing  the  TDL  tables 
database,  are  Independent  processes  and  can  be  performed  in  any  order. 
Example  JCL  for  running  the  Reader  Is  shown  In  Figure  11-6.  Setting  up 
the  Reader  JCL  Is  discussed  In  Section  7.0.  The  TDL  description  for  the 
translation  Is  shown  In  Figure  11-7.  Writing  TDL  descriptions  Is  discussed 
In  Section  4.0.  The  JCL  to  run  the  TDL  Analyzer  Is  shown  In  Figure  11-8. 

A description  of  running  the  TDL  Analyzer  can  be  found  In  Section  6.0. 

The  next  step  Is  to  run  the  Res true turer.  The  Res true turer  JCL  Is 
shown  In  Figure  11-9;  the  JCL  Is  discussed  In  Section  8.0. 

The  final  step  Is  to  run  the  Writer.  The  Writer  JCL  Is  shown  In 
Figure  11-10  and  discussed  In  Section  9.0. 


Files  Used  In 


File  name 

MICHI6AN/NPRES.61 
/IDSA1.RS 
/TRANS .LR 
/NPRES.ST 
/SDDL. AT 
/INTRN.AT 
/NPRES.PM 

/IDSA2.RS 

/PPS.61 

/PPS.ST 

/PPS.PM 

/ACIDS. SI 

/ACIDS. S2 

/NPRES.MO 

/READR.RS 

/DRT.OB 

/DRT.AT 

/INTERNAL 


Usaae 


Source  extended  MD  section 
Phase  1 IDS  Analyzer  R* 

Translator  Library 
Source  SDDL  tables 
SDDL  tables  06TF 
Internal  Work  D6TF 
Run-time  parameter  file 
(IDS  Analyzer  source) 

Phase  2 IDS  Analyzer  R* 

Target  extended  MD  section 
Target  SDDL  tables 
Run-time  parameter  file 
(IDS  Analyzer  target) 

Reader  source  IOS  Accessor  (part  1) 
Reader  source  IDS  Accessor  (part  2) 
Source  IDS  MD  section 
Reader  (IDS)  R* 

Reader  DRT  database 
Reader  DRT  DBTF 
Reader  Internal  work  file 


Source  RIF 
Source  IDS  database 
T8L  Analyzer  R* 

TOL  Analyzer  parsing  tables 
Nee  Presidential -States  TDL 
description 
TDL  tables 

SYSACC  R*  (TDL  Analyzer) 
Compatibility  R*  (TDL  Analyzer) 
TDL  duap  routine  R*  (TDL  Analyzer) 
States  target  RIF 
Restmcturer  work  database 
Restructurer  R* 

Target  IDS  file 
Writer  source  code 
Main  program  part  1 
Writer  source  code 
Main  program  part  2 
Writer  R* 


/NPRES.SR 
/NPRES.ID 
/TOL.RS 
/TDL. PT 
/NPPS.TD 

/MPPS.TT 

/SYSAC.RS 

/COMP.RS 

/TDUMP.RS 

/PPS.TR 

/WRKD6.AF 

/RESTR.RS 

/PPS.ID 

/C0B1.S 


/WRITE. RS 


TATES- IN 


HAS- LARGE-CITIES 


PRESIDENT-S 


Figure  11-1  (cont.) 
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IDS  QUERY 

* EXTENDED  SOURCE  IDS  MD  SECTION  FOR  NEW-PRESIDENTIAL  * 

♦***  **********  * »*  ft  ft  ft*»***»ft  ftftftftftftftftftftftft  ***** 


STATES- IN-UN  ION 


TYPE  IS  I RETRIEVAL  VIA  CALC  CHAIN 
PAGE-RANGE  IS  I TO  6. 

PIC  X(.1£). 


02  STATE-NAME  PIC  X(.1D). 

02  YEAR-ADMITTED  PIC  X(4)'. 

02  CAPITAL  PIC  XUO)'. 

02  AREA-SQ-MI  PIC  9(8)  USAGE  IS  COMP- 1'. 

02  AREA-RANK  PIC  9(2)  USAGE  IS  COMP-1'. 

02  POPULATION  RIC  9(8)  USAGE  IS  COMP-1. 

02  POP-RANK  PIC  9(2)  USAGE  IS  COMP-1. 

02  ELECTORAL-VOTES  PIC  9(2)  USAGE  IS  COMP-1'. 

02  TRANSLATION- INFORMAT ION. 

61  P-K'. 

61  G4  STATES- IN-UN ION,  « 

61  I * STATE-NAME. 

98  CALC  CHAIN  DETAIL 

RANDOMIZE  ON  STATE-NAME. 

98  HAS-NATIVE-PERSON  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

98  HAS-LARGE-CI TIES  CHAIN  MASTER 
CHAIN-ORDER  IS  SORTED'. 

98  ADMITTED-DURING  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER'. 

*############################# ################## 

* 

01  CITIES  TYPE  IS  2 

RETRIEVAL  VIA  HAS-LARGE-CITIES  CHAIN'. 
02  CITY-NAME  PIC  XUO)'. 

02  POPULATION-OF-CITY  PIC  9(10)  USAGE  IS  COMP-.!'. 

02  TRANSLATION-INFORMATION  SIZE  O'. 

61  P-K. 

61  G*  CITIES, 

61  14  CITY-NAME, 

61  POPULATION-OF-CITY. 

61  E-K-F*  HAS-LARGE-CITIES. 

98  HAS-LARGE-CITIES  CHAIN  DETAIL 
DUPLICATES  NOT  ALLOWED 
ASCENDING  KEY  IS  POPULATION-OF-CITY 
oELECT  CURRENT  MASTER'. 

* ####  ######  #######  ############  #######  ###  # #####  ## 

★ 


01  PRESIDENT 


02  LAST-NAME 
02  FIRST-NAME 
02  IN IT 
02  MONTH-BORN 
02  DAY-BORN 
02  YEAR-BORN 
02  HEIGHT 

02  PARTY-AFFILIATED 
02  COLLEGE 


TYPE  IS  3 

RETRIEVAL  VIA  CALC  CHAIN 
PAGE-RANGE  IS  7 TO  13'. 
PIC  XUO)'. 

PIC  XUO). 

PIC  XU). 

PIC  XUO)'. 

PIC  X ( 2 ) '• 

PIC  X(4) . 

PIC  XUO). 

PIC  XUO)'. 

PIC  XUO). 


02  ANCESTRY  NIC  X(I0>. 

02  RELIGION  PIC  X < 10) . 

02  MONTH-DIED  PIC  XUO)'. 

02  DAY-DIED  PIC  X(2>'. 

02  YEAR-DIED  PIC  XUO)'. 

02  CAUSE-OF-DEATH  PIC  XUO). 

02  FATHERS-NAME  PIC  XUO). 

02  MOTHERS-NAME  PIC  X(.IO)'. 

02  TRANSLATION- INFORMAT ION. 

61  P-K. 

61  Gt  PRESIDENT, 

61  U LAST-NAME, 

61  FIRST-NAME, 

61  I N IT  '. 

90  HAD-ADM INI STRATION  CHAIN  MASTER 
.CHAIN-ORDER  IS  AFTER. 

98  NON-ELECTION  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

98  SERVED-MITH-CONGRESS  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

98  HAD-OCCUPATION  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER'. 

98  MARRIAGE-INFO  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

98  CALC  CHAIN  DETAIL 

RANDOMIZE  ON  LAST-NAME,  FIRST-NAME. 

98  HA S-N ATI VE*-PERSON  CHAIN  DETAIL 
DUPLICATES  NOT  ALLOHED 
MATCH-KEY  IS  STATE-NAME 
SELECT  UNIQUE  MASTER 
LINKED  TO  MASTER. 

'★############################################### 

01  OCCUPATION  TYPE  IS  4 

RETRIEVAL  VIA  HAD-OCCUPATION  CHAIN. 

02  TITLE-OF-JOB  PIC  XUO). 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K. 

61  Gt  OCCUPATION, 

61  MTITLE-OF-JOB. 

61  E-K-F i HAD-OCCUPATION. 

98  HAD-OCCUPATION  CHAIN  DETAIL 
DUPLICATES  NOT  ALLOWED 
SELECT  CURRENT  MASTER. 

*################## ######  ##### ############# ###*# 


MARRIAGE-DATA 


02  NIVES-NAME  PIC  XUO). 

02  MONTH-MARRIED  PIC  XUO). 

02  DAY-MARRIED  PIC  X(IO). 

02  YEAR-MARRIED  PIC  XUO)'. 

02  NUMBER-OF-CHILDREN  PIC  XU 

02  TRANSLATION-INFORMATION  SIZE  O'. 
61  P-K’. 

61  Gt MARRIAGE-DATA, 

61  It  NIVES-NAME'. 

61  E-K-FtMARRI  AGE-INFO'. 
MARRIAGE-INFO  CHAIN  DETAIL 


TYPE  IS  5 

RETRIEVAL  VIA  MARRIAGE- 1 NR)  CHAIN'. 
PIC  XUO). 

PIC  X < 10). 

PIC  XUO). 

PIC  XUO)'. 

REN  PIC  XUO)'. 

ORMATION  SIZE  O'.  \ 


DUPLICATES  HOT  ALLOWED 
SELECT  CURRENT  MASTER'* 

01  ADMINISTRATION  TYPE  IS  6 

RETRIEVAL  VIA  CALC  CHAIN 

PA6E-RANGE  *5 -M- TO  *8t-- 

02  ADMINISTRATION-NUMBER  PIC  X(3)'. 

02  MONTH-INAUO  PIC  X(10>. 

02  DAY- IN AUG  PIC  X<2>. 

02  YEAR- IN  AUG  PIC  XM>. 

02  TRANSLATION-INFORMATION*. 

61  P-K. 

61  G* ADMINISTRATION, 

61  It 

61  ADMINISTRATION-NUMBER. 

98  CALC  CHAIN  DETAIL 

RANDOMIZE  ON  ADMINISTRATION-NUMBER* 

98  HAD-ADMINISTRATION  CHAIN  DETAIL 
SELECT  UNIQUE  MASTER 

DUPLICATES  NOT  ALLOWED  _ 

MATCH-KEY  IS  LAST-NAME,  MATCH-KEY  IS  FIRST-NAME 

LINKED  TO  MASTER*. 

98  ADMITTED-STATES  CHAIN  MASTER 

CHAIN-ORDER  IS  AFTER*. 

98  VICE-PRESIDENT-WAS  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER*. 

★################### 

01  STATES- ADMITTED  TYPE  IS  7 _ATkI 

RETRIEVAL  VIA  ADMITTED- STATES  CHAIN. 

02  TRANSLATION-INFORMATION  SIZE  0. 

61  P-K. 

61  G i STATES- ADMITTED, 

61  E-K-F* 

61  ADMITTED-STATES, 

61  ADMITTED-DURING. 

98  ADMITTED-STATES  CHAIN  DETAIL 

LINKED  TO  MASTER 
DUPLICATES  NOT  ALLOWED 
SELECT  CURRENT  MASTER. 

98  ADMITTED-DURING  CHAIN  DETAIL 

DUPLICATES  NOT  ALLOWED 
SELECT  UNIQUE  MASTER 
LINKED  TO  MASTER 
MATCH-KEY  IS  STATE-NAME*. 

★#####################  ####################PP#PP# 

01  VICE“PRESIDENTretJi£vAlSv?a  VICE-PRESIDENT-WAS  CHAIN. 

02  VP-FIRST-NAME  JIC  X(10>*. 

02  VP-LAST-NAME  PIC  XUO). 

02  TRAN SLAT ION- INFORMAT ION  SIZE  0. 

61  P-K. 

61  GiVICE-PRESIDENT, 

61  I i VP-FIRST-NAME, 

61  VP-LAST-NAME*. 

61  E-K-F t 

61  VICE-PRESIDENT-WAS 

Figure  11-2  (cont.) 
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VICE-PRESIDENT-NAS  CHAIN  DETAIL 
DUPLICATES  NOT  ALLOWED 
SELECT  CURRENT  MASTER'. 


01  ELECTION  TYPE  IS  9 

RETRIEVAL  VIA  CALC  CHAIN 
PAGE-RANGE  IS  19  TO  22. 

02  YEAR-OF-ELECTION  „ PIC  X(5). 

02  WINNER  Vt  Sr 

02  WI.NNING-PARTY  PIC  X<10>. 

02  HINNING-ELECTORAL-VOTES  PIC  X<3>. 

02  TRANSLATION- INFORMAT ION. 

61  P-K', 

61  G»  ELECTION, 

61  I * YEAR-OF-ELECTION. 

98  CALC  CHAIN  DETAIL 

RANDOMIZE  ON  YEAR-OF-ELECTION. 

98  WON-ELECTION  CHAIN  DETAIL 

SELECT  UNIQUE  MASTER  _ _ _____  U4UC 

mATCH-KEY  is  last-name,  match-key  is  first-name 

LINKED  TO  MASTER'. 

98  LOSERS-OF-E LECTIONS  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER'. 

************************************************ 

01  losers  ^rItbIeval  vu  losers-of-elections  chain 

02  LOSER-HAME  RIC 

02  LOSER-PARTY  PIC  X C 1 0 ) . 

02  LOSER-ELECTORAL-VOTES  PIC  X(3>. 

02  TRAN SLAT I ON- INFORMAT ION  SIZE  0. 

61  P-K. 

61  G« LOSERS, 

61  It  LOSER-NAME'. 

61  E-K-Ft 

61  LOSERS-OF-ELECTIONS. 

98  LOSERS-OF -ELECTIONS  CHAIN  DETAIL 
SELECT  CURRENT  MASTER 
DUPLICATES  NOT  ALLOWED. 

★ ############  ######  *************  **************** 

01  CONGRESS  TYPE  IS  II 

RETRIEVAL  VIA  CALC  CHAIN 
PAGE-RANGE  IS  23  TO  33. 

02  CONGRESS-NUMBER  PIC  X<3). 

02  TRANSLATION-INFORMATION. 


61  Gt  CONGRESS, 

61  I i CONGRESS-NUMBER. 

98  CALC  CHAIN  DETAIL 

RANDOMIZE  ON  CONGRESS-NUMBER. 

98  SENATE-MAKEUP  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER'. 

98  HOUSE-MAKEUP  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER. 

98  * SERVED-WITH-PRESIBENT  CHAIN  MASTER 


CHAIN-ORDER  IS  AFTER. 

*###################################### ######### 


01  SENATE  TYPE  IS  12 

RETRIEVAL  VIA  SENATE-MAKEUP  CHAIN 
02  SENATE-PARTY  PIC  X<!0>. 

02  SENATORS  PIC  X(2>'. 

u2  TRANSLATION-INFORMATION  SIZE  O'. 

61  P-K'. 

61  CM  SENATE, 

61  I*  SENATE-PARTY, 

61  SENATORS. 

61  E-K-FtSENATE-MAKEUP. 
t8  SENATE-MAKEUP  CHAIN  DETAIL 
SELECT  CURRENT  MASTER 
DUPLICATES  NOT  ALLOWED. 

*############################################### 


01  HOUSE  TYPE  IS  13 

RETRIEVAL  VIA  HOUSE-MAKEUP  CHAIN. 
02  HOUSE-PARTY  PIC  XMO>. 

02  REPRESENTATIVES  PIC  X<3>. 

- -82  TfrANSLATION-IN  FORMATION  SIZE  O* 

61  P-K*. 

61  G< HOUSE, 

61  14 HOUSE-PARTY, 

61  REPRESENTATIVES. 

61  E-K-F*  HOUSE-MAKEUP. 

*8  HOUSE-MAKEUP  CHAIN  DETAIL 
SELECT  CURRENT  MASTER 
DUPLICATES  NOT  ALLOWED. 

*########################################  #«##### 


01  RELATOR-PRES-CONO  TYPE  IS  14 

RETRIEVAL  VIA  SERVED-WITH-CONGRESS  CHAIN 
PAOE-RANOE  IS  34  TO  35'. 

02  TRANSLATION-INFORMATION  SIZE  O'. 

61  P-K'. 

61  04  RELATORtPRES-CONO , 

61  E-K-F» 

61  SERVED-NITH-OONORESS, 

61  SERVED-WITH-PRESIDENT'. 

98  SERyED-NITH-CONGRESS  CHAIN  DETAIL 
LINKED  TO  MASTER 
SELECT  UNIQUE  MASTER 

MATCH-KEY  IS  LAST-NAME,  MATCH-KEY  IS  FIRST-NAME 
DUPLICATES  NOT  ALLOWED’. 

98  SERVED-W ITH-PRESIOENT  CHAIN  DETAIL 
SELECT  UNIQUE  MASTER 
LINKED  TO  MASTER 
DUPLICATES  NOT  ALLOWED 
MATCH-KEY  IS  CONGRESS-NUMBER'. 

★#######  ##  ######  ###########  #############•#  ######## 

★ ###### ###  ###  ####### #######  #####  #######  #♦#####  ### 


Figure  11-2  (cant.) 
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PROGRAM  C 
FILE  i 
DATA  1 
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DATA 

CREATE  I 
NOTE 
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IDS  I 

SELECT  A 1 
FILE 
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PRMFL 

FILE 

FILE 
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PRMFL 
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PRMFL 
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NOTE 

NOTE 
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PRMFL 
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ENDJOB 
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»»****»*»*»»>»********* ********* *******  ****** ****** 

* INITIALIZE  QUERY  DICTIONARY  .,  * 

***************************************  ****** ****** 


QUTI 

A1 ,X 1 S,30R  QUERY  DICTIONARY  FILE 

I* 

1 ,360 

FG/Al  /, BSSZ/360/.RNG/J , 360/, INV/NO/ 


* CREATE  IDS  QUERY  DICTIONARY  * 

»-★»*»**■»*»****  ************************  ********  **  **** 
NDECK 

M I CH IOAN/NPRE  S.6 J 

★3,X1S  QUERY  DICTIONARY 

■FC/+3/.BSSZ/360/.RN0/.1, 360/.  INV/NO/ ............ 


* EXECUTE  IDS  ANALYZER  PHASE  1 
NREST 

25 ,63K,-2K, 30000 
R*,R,R, MICHIGAN/ IDSAI'.RS 

!u!x?R,50R  QUERY  DICTIONARY 

FC/A1  /,BSSZ/360/,RNG/.1 , 360/,  INV/NO/ 

TR,R,R, MICHIGAN/TRANS. LR 
03/Z1 S.W.R .MICHIOAN/NPRES, ST 

04,  R,S, MICHIGAN/ SDDL, AT 

05. X3R  SCRATCH  FILE 

§6  INITIALIZATION  OUTPUT 

I5,X4S,I0R  INTERNAL  WORK  DATABASE 

i! -CH.owmmj-.AT^s 

^SSi^^*^**************************1******  ****** 

* EXECUTE  IDS  ANALYZER  PHASE  2 * 

»*»»»>***»»»*************************************** 

R*,R, S,MICHIGAN/IDSA2.RS 

H*,H1R,10R 

15, 37K.-1K, 15000 

TR,R,R,MICHIOAN/TRANS.LR 

03  71 R SDDL  TABLES 

i6  SDDL  DUMP  AND  ERROR  MESSAGES 

07  SDDL  DUMP 

15 ,X4R  INTERNAL  KORK  DATABASE 


Figure  11-3 
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STATE S-S 


W £ 


TYPE  IS  1 RETRIEVAL  VIA  CALC  CHAIN 
PA~E-RANGE  IS  l TO  6. 

PIC  X(U». 

PIC  X (4)  • 

PIC  XUO)'. 

PIC  9<a>  USAGE  IS  COMP-1. 
PIC  9(2)  USAGE  IS  COMP-1 . 
PIC  9(8)  USAGE  IS  COMP-1'. 
PIC  9(2)  USAGE  IS  COMP-1. 
PIC  9(2)  USAGE  IS  COMP-1. 


__  STATE-NAME 
•2  YEAR-ADMITTED 
02  CAPITAL 
02  AREA-SQ-MI 
02  AREA-RANK 
02  POPULATION 
02  POP-RANK 
02  ELECTORAL-VOTES 

02  ADMITTED-BY-ADMIN 
02  TRANSLATION- INFORMAT ION. 
o.l  P-K. 

6:  GiSTATES-S, 

6.1  I*  STATE-NAME'. 
HAS-NATIVE-PERSON  CHAIN  MASTER 
CHAIN-ORDER  IS  AFTER'. 

CALC  CHAIN  DETAIL 

RANDOMIZE  ON  STATE-NAMEo 
HAS-LARGE-CITIES  CHAIN  MASTER 
CHAIN-ORDER  IS  SORTED. 


98 

98 


98 


OJ  CITIES 


TYPE  IS  2 

RETRIEVAL  VIA  REFCODE-CITIES  FIELD, 

02  REFCODE-CITIES 
02  CITY-NAME  PIC  X(.IO). 

02  POPULAT ION-OF-C ITY  PIC  9(10)  USAGE  IS  COMP-1. 

02  TRANSLATION-INFORMATION'. 

6 1 h-K'. 

6.1  Gt  CITIES, 

61  l*  CITY-NAME, 
ot  POPULAT ION-OF-C ITY. 

61  E-K-F  t 

HAS-LARGE-CITIES, 


* EXTENDED  TARGET  IDS  MD  M ((tMM 


61 


V I i in  w — — — — 

98  HAS-LARGE-CITIES  CHAIN  DETAIL 


Figure  11-4 
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duplicates  not  allowed 

- ASCENDING  KEY  IS  CITY-NAME 
SELECT  CURRENT  MASTER. 

* ####  #«####  ################*##  ##  ***** ** ****  ***** 

01  PRESIDENT-S  TYPE  IS  3 

RETRIEVAL  VIA  REFCODE-P-S 
•2  REFCODE-P-S  PIC  9(8). 

02  PRES-S-LNAME  PIC  XdO)'. 

02  PRES-S-FNAME  PIC  X(IO). 

02  P.RES-S-MNAME  PIC  X(l)'. 

02  TRANSUTION-INFORMATION'. 

01  P-K*. 

61  G<  PRESIDENT-S. 

61  I*  PRES-S-LNAME. 

61  PRES-S-FNAME . 

61  PRES-S-MNAME. 

98  HAS-NATIVE-PERSON  CHAIN  DETAIL 
DUPLICATES  NOT  ALLOWED 
SELECT  CURRENT  MASTER. 

98  PRES-INFO  CHAIN  MASTER 

CHAIN-ORDER  IS  AFTER. 

★ ###  #####f  #####69  ######  ######  #######  ######  ###### 

01  OCCUP-MARR  TYPE  IS  4 

RETRIEVAL  VIA  PRES-INFO  CHAIN. 
02  TITLE-OF-JOB  PIC  X (.10) . 

02  WIVES-NAME  PIC  X(10)'. 

02  MONTH-MARRIED  PIC  X(40>. 

02  DAY-MARRIED  PIC  X(10>. 

02  YEAR-MARRIED  PIC  X(IO). 

02  NUMBER-OF-CHILDREN  PIC  X(10). 

02  TRANSUTION-INFORMATION  SIZE  0. / 

61  P-K. 

6.1  G<  OCCUP-MARR, 

6.1  I*  TITLE-OF-JOB, 

61  WIVES-NAME. 

61  E-K-FtPRES-INR). 

98  PRES-INFO  CHAIN  DETAIL 

SELECT  CURRENT  MASTER. 


FIELD'. 


Figure  11-4  (cont.) 
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FILE 
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REMOTE 
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EXECUTE 

PRMFL 
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PRMFL 

FILE 

REMOTE 
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ENDJOB 


★★★^hhw>**^*»»****»»»**»*«*  *»»  « fit****************** 

* INITIALIZE  QUERY  DICTIONARY 

»«»»»»»★»**»  ★»»★★♦♦♦★***  **** 

OUT  I 

At  «X IS«30R  QUERY  DICTIONARY  FILE 

I* 

1,360 

* Q 

FC/AI/,BSSZ/360/,RNG/.l , 360/,  INV/NO/ 
★»»^*»»^*»*********  ****************  ************** 

* CREATE  IDS  QUERY  DICTIONARY  * 

*****^***Hr************************** ********  ****** 

NDECK 

MICH IGAN/PPS. 6 1 

*3,X1 S QUERY  DICTIONARY 

* Q 

FC/*3/,BSSZ/360/,RNG/J , 360/, INV/NO/ 
*************************************************** 

* EXECUTE  IDS  ANALYZER  PHASE  1 * 

*************************************************** 
NREST 

25 «63K,-2K, 30000 
R*,R,R,MICHIGAN/IDSA1 .RS 
H*,X2R,50R 

AI.X1R  QUERY  DICTIONARY 

;q 

FC/AI  / , B 5SZ/360/ , R NG/-1 , 360/  , I NV/NO/- 

TR,R,R,MICHIGAN/TRANS.LR 

03/Z I S,  N , R , MI  CH IGAN/PPS . ST 

04,  R,  S.MICHIGAN/SDDL.AT 

05, X3R  SCRATCH  FILE 

06  INITIALIZATION  OUTPUT 

I5«X4S, 10R  INTERNAL  WORK  DATABASE 

16,R,S,MICHIGAN/INTRN.AT 

A3  ERROR  MESSAGES 

A5 

MICH IGAN/PPS. PM 

*********************** **************** ************ 

* EXECUTE  IDS  ANALYZER  PHASE  2 * 

********************************  *** **  ************** 

R*,R,S,MICHIGAN/IDSA2'.RS 

H*,HI R, 10R 

15, 37K, -IK, 15000 

TR,R,R,MICHIGAN/TRANS'.LR 

03,Z1R  SDDL  TABLES 

00  SDDL  DUMP  AND  ERROR  MESSAGES 

07  SDDL  DUMP 

.1 5,X4R  INTERNAL  WORK  DATABASE 


Figure  11-5 
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IDS  , NDECK 
SELECT A N I CH I GAN/ ACIDS'. SI 
SELECTA  MICHIGAN/NPRES'.MD 
SELECTA  NICHICAN/ACIDS.S2 
NOTE 
NOTE 
NOTE. 

EXECUTE 

PRMFL  R*,R,  S.MICHIGAN/READR.RS 
FILE,  H*,Y1 R, 15R 
LIMITS  30, 60K,-5K, 50000 
PRMFL  TR,R,R,MICHIGAN/TRANS.LR 
PRMFL  OJ,W,R,MICHIGAN/DRT.DB 
PRMFL  02,W,R,MICHIGAN/DRT'.AT 
PRMFL  04, W,S, MICHIGAN/INTERNAL 
DATA  05 

FIRST  LAST  NAME*NEW-PRESIDENTIAL 
REMOTE  06 

PRMFL  07,N,R,MICH IGAN/NPRES • ST 

PRMFL  09, N,R, MICH IGAN/NPRES. SR 

FILE  tO,R2R, 10L 

FILE  I2,R3R,10L 

FILE  13, NULL 

PRMFL  XI ,R,R,MICHIGAN/NPRES. ID 
ENDJOB 


< ACCESSOR  IDS-COBOL  COMPILATION 


< EXECUTE  THE  READER 


READER  R*  FILE 


SET  CORE  AND  CPU  LIMITS 
TRANSLATION  LLBRARY 
DRT  DATABASE 
DRT  ADBMS  FILE 
READER  INTERNAL  FILE 


RECORDS-ALL 
REPORT  OUTPUT 
SDDL  TABLE  DATABASE 
SOURCE  RIF 
SCRATCH  FILE 
SCRATCH  -FILE 

SOURCE  IDS  DATABASE 
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/★  NEW  PREZ  TO  PREZ  PARTS  STATES  */ 

/*  $L  */ 

TARGET  RECORD  CITIES 

TDLASOURCE  RECORD  STATES- IN-UN ION  ACCESS  VIA  CALC-STATES -IN-UN ION 
SOURCE  RECORD  CITIES  ACCESS  VIA  HAS-LARGE-CITIES 
ACTUAL  DATA  IN  ORDER 
SET  SIGNIFICANT  DATA  BY  NAME 
TARGET  RECORD  OCCUP-MARR 
TDLAP  OCCU 

SOURCE  RECORD  PRESIDENT  ACCESS  VIA  CALC-PRESIDENT 
FIRST-NAME  ASSIGN.  TO  PRES-S-FNAME<PRES-INFO> 

IN  IT  ASSIGN  TO  PRES-S-MNAME<PRES-INFO> 

LAST-NAME  ASSIGN  TO  J>RES-S-LNAME$PRES-INF0> 

SOURCE  RECORD  OCCUPATION  ACCESS  VIA  HAB-OCCUPATION 
TITLE-QF-JOB  ASSIGN  TO  TITLE-OF-JOB 
SOURCE  RECORD  MARRIAGE-DATA  ACCESS  VIA 
MARRIAGE- INFO  FROM  PRESIDENT 
WIVES-NAME  ASSIGN  TO  WIVES-NAME 
MONTH-MARRIED  ASSIGN  TO  MONTH-MARRIED 
DAY-MARRIED  ASSIGN  TO  DAY-MARRIEB 
YEAR-MARRIED  ASSIGN  TO  YEAR-MARRIED  „ 

NUMBER-OF-CHILDREN  ASSIGN  TO  NUMBER-OF-CH ILDREN 

TARGET  RECORD  PRESIDENT-S 
TDLAP  PRES 

SOURCE  RECORD  PRESIDENT  ACCESS  VIA  CALCePR ESI DENT 
SET  SIGNIFICANT  DATA  BY  NAME 
FIRST-NAME  ASSIGN  TO  PRES-S-FNAME 
I NIT  ASSIGN  TO  PRES-S-MNAME 
LAST -NAME  ASSIGN  TO  PRES-S-LNAME 
TARGET  RECORD  STATES-S 
tdlaP  STAT 

SOURCE  RECORD  STATES- IN-UN ION  ACCESS  VIA  CALC-STATES-IN-UNION 
STATE-NAME  ASSIGN  TO  STATE-NAME 
YEAR-ADMITTED  ASSIGN  TO  YEAR-ADMITTED 
CAPITAL  ASSIGN  TO  CAPITAL 
AREA— SQ-MI  ASSIGN  TO  AREA-SQ-MI 
AREA-RANK  ASSIGN  TO  AREA-RANK 
POPULATION  ASSIGN  TO  POPULATION 
POP-RANK  ASSIGN  TO  POP-RANK 
ELECTORAL-VOTES  ASSIGN  TO  ELECTORAL -VOTES 

SOURCE  RECORD  STATES-ADMIJTED  ACCESS  VIA  ADWITTEB-DUR ING 
ACCEPT  IF  NULL 

SOURCE  RECORD  ADMINISTRATION  ACCESS  VIA 


I DENT 
MOTE 
NOTE 
NOTE 
NOTE 
NOTE 
UTILITY 
FUTIL 
PRMFL 
FILE 
FUTIL 
PRMFL  ' 

FILE 
NOTE 

... 

NOTE  * EXECUTE  TDL  ANALYZER 

NOTE  * 

NOTc  *★★**★***★****★★★*★*★*★*★***•*•**** 

EXECUTE  NREST 

LIMITS  ,43K,-3K 

PRMFL  R*. R. S.M ICHIGAM/TOL .Rc 

FILE  H*«Z1R.40R 

PRMFL  04 , R ,S.M  I CH I GAN/TDL . r'T 

DATA  02,. tO ^Y 

SELECT  A MICHIGA^/nPPS.TD, 

ENDCOPY 

NOT’"  ANALYZER  OUTPUT  IS  ON  FILE  CORE  O 

FILE  07 , X 1 R 

FILE  0O.X2R 

PRMFL  I 1,/i.R,  aCHIGAN/NPP^.TT 

PRMFL  12.P.S.ADS’<s  TABLE  FILE  =0°  TDL  T 

FILE  I 3,. nULL 

FILE  1 4,  NULL 

PRMFI  TR, R ,R , UCHIGAN/TRANS'.y.P 

IF  1 8,  IF  IF  TDL  ERRORS  THE 

note  *■***★*♦★*+★★*★***-* •*★****+***+-**  ** 

NOTE  * 

NOTE  * PCVST  PROCESS  I - SYS ACC  PI 

NOTE  * 

noTE  **++****+**+*+•*****++*++****++ +*i 

EXECUTE  NREST 
LIMITS  , 33K ,-3K 

PRMFL  R*.R,S,MICHIGAN/SYSAC.RS 

PRMFL  0 7 , I* , R , M I CD  I G A N/NP  P S’.  TT 

FILE  08 ,X2S 

PRMFL  TR,k,R,MICHIGAN/TRANB.LR 


COPY  SOURCE  AND  TARGET  SUDL  TASL 


14,  I5.RM:)/|4/.RC0PY/1F/ 

1 4 , « . R , >•»  ICM IG  A.M/NPRES'.  ST 

15.  X IS. 4R 

16. I 7.RXD/16/.RC0PY/1 F/ 

1 6 . R . R . M I CH  IG  A M/ PP  S'.  ST 
17.X2S.4R 


* POST  PROCESS  II  - CO**pATIcILITv  PUILDE3 


n 
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PRMFL 

PRMFL 

FILE 

PRMFL 
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IF 

EXECUTE 

LIMITS 

PRMFL 

PRMFL 

NOTE 

PRMFL 

END JOB 


NPEST 
33K  -3K 

5* . P ! S , M I CH IG  4 N/OOMP . O-S 
07 , W , R , M ICH IGAN/NPPS . TT 
00 ,X2S 

TR, R. R.M ICH IG AN/TRANS. LP 

* **  **+-*•■*■•*•  ******★★★■*•★*★***★★★★★+•*★*★**■**★***  *-v 

* * 

* TDL  TAPLE  DUMPER  * 

* * 
*************+*********'******,4**-*+*****  **+++•  :* 

1 9, ENDJOM  SKIP  DUMP  IF  NOT  REQUESTED 

MDU«P 

,25K,-3< 

R*,R,  S,  MICH  IGA  N/TD'JMP  *.  R S 
02 , o , R , M I CH IG 4 N/NPPS. TT 
DUMP  OUTPUT  IS  ON  FILE  CODE  06 
TP , K . R ♦ M I CH I G A N/TR ANS . L P 


Figure  11-8  (cont,) 


I DENT  MICHO.MICHIOAN 

NOTE 

MOTE  »»»*»**»**»*»»*»****»*»1HHt»<i*»»»»»»>»**»*»»**»********^ 
MOTE  * ACTIVITY  OJ  — ALL  DATABASES  TO  BE  USED  BY  THE  * 

NOTE  * RESTRUCTURER  ARE  COPIED  FIRST  TO  PROTECT  THE  + 

NOTE  * ORIGINALS'.  BE  SURE  TO  PUT  THE  CORRECT  SIZES  «! 

NOTE  * (IN  RANDOM  LINKS)  ON  THE  IFILE  CARDS.  * 

MOTE  »^*»»*»^****^<hhmwwt<whhhm>»»****»*»*»***  » **  *»»»»* 

UTILITY 

NOTE 

FUTIL  0) ,02,RC0PY/1F/  , 

PRMFL  01 ,R,R.¥ICHIGAN/NPRES. SR 
FILE  02«X0S,6R 
NOTE 

FUTIL  03,04,RC0PY/1F/ 

PRMFL  03.N » R ,MICHIGAN/PPS.TR 

FILE  04,XIS,3R 

NOTE 

FUTIL  05,06,RCOPY/»F/ 

PRMFL  05,R,R,MICHIGAN/NPPS.TT 

FILE  06,X2S,3R 

NOTE 

FUTIL  07,08,RCOPY/1F/ 

PRMFL  07,R,R.,MICHIGAN/NPPS.TT 

FILE  08,X3S,3R 

NOTE  ! 

FUTIL  09, 10,RC0PY/1 F/ 

PRMFL  09,R^|,MJCHI0AN/PPS.ST 

NOTE 

FUTIL  .1 1 , 12,RC0PY/.IF/ 

PRMFL  1 1 ,R,R,MICHIOAN/NRKDB.AF 

FILE  12,X5S, 12R  1 

NOTE 

NOTE  »♦★»»»»»»»»»»*  a******************************* 

NOTE  * ACTIVITY  02  — RUN  THE  RESTRUCTURER.  ONOTE  THAT  i 

NOTE  • * THE  SLIM ITS  CARD  MUST  BE  ADJUSTED  FOR  EACH  * 

NOTE  * PARTICULAR  RESTRUCTURING  JOB. 

MOTE  »<HHIr»»-<Nr*»»«>»»»»»*******«HH>*»»»»»*»**»»»*****»********1 

EXECUTE  DUMP,NREST 

LIMITS  40,65K,-5K  , 

PRMFL  R*,R, S.MICHIGAN/RESTR.RS  \ 

FILE  H*,,40R  ' 

PRMFL  TR,R,R,MICHIGAN/TRANS.LR 

NOTE 
NOTE 
NOTE 
NOTE 
NOTE 


THE  FOLOMING  SIX  $FILE;  CARDS  CORRESPOND 
TO  THE  SIX  DATABASES  COPIED  IN  ACTIVITY  01 


Figure  11-9 


TAUGHT  RTF  (SAVED  FOR  ACTIVITY  03) 
'NAMES'  TOL  TABLES 
'POINTERS'  TDL  TABLES 

Target  sddl  tables 

DDL-WUTER  WORK  DATABASE 


THE  PoLLONING  FOUR  tFILE  CARDS  ARE  USED 
IN  THE  PREPARATION  OF  THE  TARGET  RIF  FOR 
RESTRUCTURING 


OUTPUT  SINK  (DDL A*  DBINT) 

DDL  TEXT  FOR  TARGET  RIF 
OBTF  FOR  TARGET  RIF  .......  - 

ITSER  -HASH  INPUT  FILE  TO  DBINT 


I,,  FILE  03 

F ' FILE  " 04  ~ 

* NOTE  

$ NOTE 

$ DATA  05,, COPY 

#translation-name«new-presidential-to-presidents-parts-states 
#run«initialize 
#execution-mon itor-off 
#active-tdlap$ 

ALL-TDLAPS- ACTIVE 

#END-USER~INPUT  - 

$ ENDCOPY 

$ NOTH 

$ NOTE 

S NOTE 

$ NOTE 

$ NOTE 

I NOTE 

$ NOTE 

I NOTE 


* ACTIVITY  03  — COPY  THE  MEN  TARGET  RIF  DATABASE  * 

* BACK  TO  THE  PERMANENT  FILE.  IF  THE  RESTRUCTURER  * 

* ENCOUNTERED  AN  ERROR  IN  ACTIVITY  02.  THE  $IF  CARD  * 

* NILL  PREVENT  OVERWRITING  THE  OLD  TARGET  DATABASE  * 

* FILE:  WITH  THE  (POSSIBLY  INCONSISTENT)  NEN  ONE.  * 

.........  . . . . * « « « « « » « » * « » * * * * * *-  » « » » * * *■  -* — »-»-  -* — 


35, END JOB 


UTILITY 

FUTIL  01 ,02,RCOPY/J  F/ 

FILE  01 ,XfR 

PRMFL  02,N,R,MICHIGAN/PPS,TR 
ENDJOB 


Figure  11-9  (cont.) 


NOTE  * EXECUTE  THE  HR  ITER  JCL  * 

MOTE  -V  * * 

MOTE  * UTILITY  CORY  OF  TARGET  RIF  INTO  TEMR.  FILE  * 

note  ***************************  »****»»*»*  **  o »**»»&**** 

UTILITY 

FUTIL  A1,A2,RC0RY/1F/ 

RRMFL  A»,R,R,MICHIGAN/RRS'.TR 

NOTE  it*  »»»»»*»»***»****»*»»»  *******  ***************  ****** 

NOTE  * IF  THIS  IS  THE  FIRST  RUN  J) N A TARGET  * 

NOTE  * DATABASE,  THEN  INCLUDE  THIS  ACTIVITY,  * 

NOTE  * ELSE  SKIP  DOHN  TO  THE  COMPILATION  * 

MOTE  ^ * 

NOTE  * INITIALIZE  TAAOET  IPS  DATABASE  * 

NOTE  ** ****** * * ***  ******  »»»»»»♦»»♦»***»♦** »»»»♦»★»★»»*«♦ 

PROGRAM  OUT I 

RRMFL  XI ,REC,R, MICHIGAN/ RRSVID 


INCLUDE  EITHER-  _ 

$ FILE  t6«X2R,2L  IF  ALL  RECORDS  ARE  MRITTEN 

THIS  RUN 

OR— 

$ RRMFL  1 6,  M,S,. BETWEEN  RUNS  SAVE  FI l£  IF  ONLY 
PARTIAL  DATABASE  HRITE  IS  MADE 


FILE  16,X2R,2L 

RRMFL  XI,REC,R,MICHIOAN/RRS.ID 

RRMFL  TR,B,B,MICHIOAN/TRANS.LR 

uqtc  ♦ »*>»»***  A*  **>*»*>>****♦  MAP  *******  **************** 

NOTE  * GO  TO  ENDJOB  IF  UNSUCCESSFUL  NR ITER  RUN 
NOTE  * ELSE  CORY  UPDATED  RIF  BACK  TO  RRMFL  * 

NOTE  »♦♦»♦*»»»»***»»»*»***** **************************** 

IF  /35, ENDJOB 

UTILITY  ■ 

FUTIL  A1,A2,RC0RY/1F/ 

FILE  Al ,X1R  M ,, 

RRMFL  Al.W.R.MICHlOAN/BRS'.TR  Figurp  11-10 
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APPENDIX  A 
IDS  ANALYZER  ERRORS 

Documentation  for  all  IDS  Analyzer  errors  appears  In  this  appendix. 
Each  error  message  Is  given  a number  and  cross-references  are  sometimes 
made.  Information  concerning  the  fatal /nonfatal  nature  of  the  error, 
the  activity  In  which  the  error  occurs,  the  cause,  and  the  action  to  be 
taken  to  correct  each  error,  are  given. 

Almost  every  error  message  Is  accompanied  by  .the  following  output: 

***ERROR. ..error  message  text 

CURRENT  DATABASE  IS  - **** 

CURRENT  01  RECORD  IS  » **** 

CURRENT  02  FIELD  IS  * **** 

CURRENT  VALIDATION  IS  * **** 

CURRENT  61  LEVEL  IS  - **** 

By  examining  the  values  of  the  current  database,  record,  etc.  being 
processed.  It  Is  relatively  easy  for  the  user  to  examine  the  extended 
MD  section  to  locate  syntax  and  semantic  errors. 

Except  for  serious  IDS  Analyzer  errors  such  as  table  overflow  or 
exposed  Invalid  program  logic,  no  error  Is  fatal  to  execution  although 
occurrence  of  one  syntax  error  may  propagate  several  more.  All  user- 
correctable  errors  should  be  eliminated  by  appropriate  modification 
to  the  extended  MD  section.  The  IDS  Analyzer  then 
should  be  rerun.  There  Is  no  need  to  erase  the  previously  built  Invalid 
SDOL  tables  file. 

All  error  messages  are  sorted  alphabetically  to  allow  easy  reference. 
The  collating  sequence  observed  Is: 

1)  Numeric  characters 

2)  Alphabetic  characters 

3)  Special  characters 


1.  "WARNING:  UNABLE  TO  GENERATE  USER  SUPPLIED  SYS-ENTRY  POINT.  PROBABLE 
CAUSE  - NAME  SUPPLIED  IS  NON-UNIQUE." 

Cause:  User  has  attempted  to  override  IDS  Analyzer's  automatic  system 
entry  relation  name  generator  by  supplying  a nonunique  name  for 
the  relation  In  a 61  level  SYS-ENTRY.  This  a nonfatal  error  In 
activity  3. 

Action:  If  the  user  still  wishes  to  rename  the  relation,  the  relation 

name  given  In  the  61  level  must  be  changed  so  that  It  Is  unique. 

No  action  Is  necessary  If  the  name  generated  by  the  IDS  Analyzer 
Is  acceptable  to  the  user. 

2.  "***ABNORMAL  TERMINATION  IN  IDS  ANALYZER  DUE  TO  ABOVE  ERROR." 

Cause:  The  IDS  Analyzer  has  encountered  an  error  from  which  It  could 

not  recover.  This  Is  a fatal  error  In  activity  3. 

Action:  Analyze  the  error  message  directly  above  this  and  take  the 
appropriate  action. 

3.  "***FATAL  ERROR.. NON-ZERO  RETURN  CODE  FROM  ADBMS  SYSTEM.  CONTACT 
DATA  TRANSLATION  PROJECT." 

Cause:  The  database  management  system  supporting  the  IDS  Analyzer  has 

encountered  an  error  in  the  Analyzer  logic.  This  Is  a fatal  error 
In  activity  3. 

Action:  The  user  should  not  attempt  to  find  the  error.  Contact  the  Oata 
Translation  Project. 

4.  "***£RR0R  IN  'AOHASL'  - DUPLICATE  DISPLACEMENTS." 

Cause:  Program  logic  error.  It  Is  fatal  and  occurs  In  activity  3. 

Action:  Contact  the  Data  Translation  Project. 

5.  "***ERR0R  IN  'ADHASL'  - INVALID  TYPE  VALUE." 

Cause:  An  IOS  Analyzer  support  routine  has  been  passed  an  <nval1d 
parameter.  It  Is  a fatal  error  which  occurs  In  activity  3. 

Action:  Contact  the  Data  Translation  Project. 

6.  "***ERR0R...01  RECORD-NAME  NOT  IN  PARAMETER  FILE" 

Cause:  The  IDS  Analyzer  has  encountered  an  01  record  In  the  IDS  Query 
dictionary  which  was  not  defined  by  the  user  In  the  parameter 
file.  It  Is  a nonfatal  error  which  occurs  In  activity  3. 


Action:  Insert  the  nine  of  the  01  record  Into  the  parameter  file  and 
rerun  the  Analyzer. 

7.  "***ERR0R. . .ADBMS  ERROR  IN  ROUTINE  BLDKEY  AT  StMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while 

using  Its  database  management  system.  ADBMS.  It  Is  a fatal  error 
which  occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 

8.  "***ERR0R. . .ADBMS  ERROR  IN  ROUTINE  BLDVIR  AT  STMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while 

using  Its  database  management  system,  A06MS.  It  Is  a fatal  error 
which  occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 

r i'  Hit  :i':.  i.  Xi».-  C< 

9.  "***ERR0R. . . ADBMS  ERROR  IN  ROUTINE  CREVIS  AT  STMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while  using 
its  database  management  system,  ADBMS.  It  is  a fatal  error 
which  occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 

10.  "***6RR0R... ADBMS  ERROR  IN  ROUTINE  ERRPK  AT  STMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while  using 
Its  database  management  system,  ADBMS.  It  Is  a fatal  error  which 
occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 

11.  "***ERR0R. . .A08MS  ERROR  IN  ROUTINE  INITDS  AT  STMT-" 

Cause:  An  Analyzer  support  routtne  has  encountered  an  error  while  using 
Its  database  management  system,  ADBMS.  It  Is  a fatal  error  which 
occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 

12.  "TERROR... ADBMS  ERROR  IN  ROUTINE  KEYACT  AT  STMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while 

using  Its  database  management  system,  ADBMS.  It  Is  a fatal  error 
which  occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 


13.  "***ERROR. . .ADBMS  ERROR  IN  ROUTINE  LNKEY  AT  STMT-" 

Cause:  An  Analyzer  support  routine  has  encountered  an  error  while  using 
Its  database  management  system,  ADBMS.  It  Is  a fatal  error  which 
occurs  In  activity  4. 

Action:  Contact  the  Dote  Translation  Project. 


14.  "***ERR0R... ADBMS  ERROR  IN  ROUTINE  PROPV  AT  STMT- 


Cause:  An  Analyzer  support  routine  has  encountered  an  error  while 

using  Its  database  management  system,  ADBMS.  This  fatal  error 
occurs  In  activity  4. 

Action:  Contact  the  Data  Translation  Project. 


***ERR0R...AN  ITEM  RECORD  HAS  NO  NAME  ON  THE  INAME  SET 


An  attempt  to  determine  If  an  Item  specified  by  the  user  as 
a primary  key  of  a record  actually  Is,  an  Item  In  that  record 
has  failed  due  to  IDS  Analyzer  logic.  This  nonfatal  error 
occurs  In  activity  3. 

Action:  Contact  the  Oata  Translation  Project.  SDOL  tables  generated 
by  this  run  of  the  Analyzer  should  not  be  used. 


Cause 


1 6 .  "***ERR0R. . . COLON  EXPECTED  AFTER  NAME , NOT  FOUND1 


Cause 


The  syntax  rules  of  the  Analyzer  called  for  a delimiting  colon  In 
a 61  level  entry.  This  nonfatal  error  occurs  In  activity  3. 

Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  was  operating  when  the 
error  occurred.  Insert  the  colon  In  the  proper  place. 


Action 


17.  "***ERR0R... COMMA  EXPECTED  AFTER  NAME,  NOT  FOUND." 

Cause:  The  syntax  rules  of  the  Analyzer  called  for  a delimiting  comma 
In  a 61  level  entry.  This  nonfatal  error  occurred  In  activity  3 

Action:  Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  was  operating  when  the 
error  occurred.  Insert  the  comma  In  the  proper  place. 


18.  "***ERR0R... CURRENTLY  IMPOSSIBLE  TO  GENERATE  A UNIQUE  CONCAT-RELAY-NAME 
CODE  MUST  BE  MODIFIED." 

Cause:  The  Analyzer  was  unable  to  generate  a unique  relation  name  for  a 
contalned-ln-repeatlng  group  being  modeled  as  a master/detall 
relation.  This  nonfatal  error  occurred  during  activity  3. 


Action;:  Change  the  name  of  the  contalned-ln-repeatlng  group  to  one  whose 
first  twelve  characters  are  unique.  Rerun  the  IDS  Analyzer. 


19.  "***ERR0R...DB  TYPE  SPECIFIED  IN  PARAMETER  FILE  IS  NOT  ISP,  IDS,  OR 

SEQ" 

Cause:  The  first  line  of  the  parameter  file  did  not  properly  Identify 
the  database  on  which  the  Analyzer  will  work  as  being  IDS,  ISP, 
or  Sequential.  This  fatal  error  occurred  In  activity  3. 

Action:  Check  the  first  line  of  the  parameter  file  to  Insure  that  It 
Is  In  proper  format. 


20.  "***ERR0R. . . DEPENDENT  KEY  ITEM  OF  MATCH-KEY  RELATION  HAS  NOT  DEFINED 

Cause:  The  Item  which  the  user  has  specified  as  a dependent  key  In  a 

match-key  relation  does  not  exist.  This  nonfatal  error  occurred 
in  activity  3. 

Action:  Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  detected  the  error. 

Make  sure  the  dependent  key  Item  actually  Is  an  Item  In  the 
dependent  record  and  that  It  Is  spelled  properly. 


21.  "***ERR0R. . .DEPENDENT  SPECIFIED  IN  MATCH-KEY  RELATION  IS  UNDEFINED 


Cause:  The  record  type  which  the  user  has  specified  as  a dependent  In 
a match-key  relation  does  not  exist.  This  nonfatal  error 
occurred  In  activity  3. 

Action:  Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  detected  the  error. 
Make  sure  the  dependent  record  actually  Is  a record  In  the 
augnented  IDS  MD  section  and  that  It  Is  spelled  properly. 


22.  "***ERR0R. . .DUPLICATE  ITEM  DISPLACEMENTS  WITHIN  GROUP 


Cause:  Program  logic  error.  It  Is  fatal  and  occurs  In  activity  3 
Action:  Contact  the  Data  Translation  Project. 


23.  "***ERR0R... ERRONEOUS  DESCRIPTION." 

Cause:  A 61  level  has  been  encountered  by  the  Analyzer  which  It  Is 

unable  to  evaluate.  This  nonfatal  error  occurred  In  activity  3 

Action:  Check  the  output  following  the  error  message  to  determine  the 
61  level  which  Is  at  fault  and  the  context  In  which  It  appears. 
Be  certain  that  all  the  rules  for  coding  61  levels  have  been 

obeyed.  f ^ W pipit 


24.  "***ERROR. . . EXPECTED  NEXT  DELIMITER  IS  or 

Cause:  The  syntax  rules  of  the  Analyzer  called  for  a delimiting  period 

or  semi-colon  In  a 61  level  entry.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  was  operating  when  the 
error  occurred.  Insert  the  correct  delimiter  as  specified  In 
Sections  3. 3-3. 7. 


25.  "***ERR0R... EXPECTED  NEXT  DELIMITER  IS  V OR  OR  *.*" 

Cause:  The  syntax  rules  of  the  Analyzer  called  for  a delimiting  comma, 

semi-colon,  or  period  In  a 61  level  entry.  This  nonfatal  error 
occurred  In  activity  3. 

Action:  Inspect  the  output  Immediately  following  the  error  message  to 
determine  at  which  61  level  the  Analyzer  was  operating  when  the 
error  occurred.  Insert  the  correct  delimiter  as  specified  in 
Sections  3. 3-3. 7. 

26.  "***ERR0R. . .EXPECTING  GROUP  NAME  TO  FOLLOW  KEYWORD  'GROUP*.  NOT 
FOUND." 

Cause:  A 61  level  entry  which  was  to  supply  the  Analyzer  with  the  name  of 
the  group  whose  primary  key(s)  would  be  specified  next,  had  no 
group  name  In  It.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  Immediately  follows  the  error  message, 
determine  which  01  record  the  Analyzer  was  processing  and  in 
which  61  level  the  error  occurred.  Insert  the  proper  group  name 
after  the  keyword  "GROUP:"  or  "G:". 


27.  "***ERR0R. . .EXPECTING  ’ITEM  INFORMATION.'  CLAUSE" 

Cause:  If  a 61  level  Is  coded  beneath  an  Item  within  the  extended  MD 

section.  It  must  be  OCCURS,  EOG,  DO-NOT-RESTRUCTURE.  or  ITEM- 
INFORMATION.  The  IDS  Analyzer  checks  for  I TEA-INFORMATION , hence 
this  message  will  appear  If  one  of  the  above  clauses  does  not 
appear.  This  Is  a nonfatal  error  In  activity  3. 

Action:  Refer  to  section  3.0  of  the  User  Manual  for  correct  rules  on 
constructing  level  61  entries.  Rerun  the  IDS  Analyzer. 


28.  "***ERR0R... EXPECTING  KEYWORD  'GROUP'  OR  'G'.  PROCESSING  CONTINUES." 

Cause:  The  preceding  61  level  description  alerted  the  Analyzer  that 

Information  on  a group's  primary  key(s)  would  follow  In  subsequent 
61  levels.  In  this  situation  the  Analyzer  scans  for  the  character 
string  "GROUP"  or  "G".  The  error  occurred  because  neither  was 
found.  This  nonfatal  error  occurred  In  activity  3. 
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Action:  Using  the  output  which  follows  the  error  message*  determine  where 
In  the  augmented  IDS  MD  section  the  error  occurred  and  make  sure 
that  the  61  level  coding  reflects  the  user's  Intent  and  follows 
IDS  Analyzer  rules. 


29.  "***ERR0R. . . EXPECTING  KEYWORD  'ITEMS'  OR  'E-K-F'  TO  FOLLOW  KEYWORD 

'GROUP'.  NOT  FOUND." 

Cause:  The  61  level  which  Immediately  follows  a 61  level  description  with 
the  keyword  'GROUP'  in  It  must  contain  either  the  keyword  'ITEMS' 
or  'I'  or  ‘EXTERNAL-KEYS-FROM’  or  'E-K-F'.  This  nonfatal  error 
occurred  in  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  where 
In  the  augmented  IDS  MD  section  the  error  occurred  and  correct  the 
61  level  descriptions  so  that  the  Analyzer  can  extract  the 
necessary  Information  about  the  current  group's  primary  key(s). 


30.  ”***ERR0R. . . EXPECTING  KEYWORD  ' RELATION' . NOT  FOUND. " 

Cause:  When  the  user  Is  implementing  phantom  pointer  or  match-key 

relations  through  61  level  descriptions.  Analyzer  syntax  rules 
require  the  user  to  supply  a unique  name  for  this  relation.  The 
name  must  be  preceded  by  the  keyword  'RELATION'  or  'R'.  This 
nonfatal  error  occurred  in  activity  3. 

Action:  Using  the  output  which  Immediately  follows  the  error  message, 

determine  where  In  the  augmented  IDS  MD  section  the  error  occurred. 
Correct  the  61  levels  so  that  they  conform  to  the  syntax  rules  as 
described  In  Section  3.6.2  for  phantom  pointers,  or  Section  3.6.1 
for  match-key  relations. 

31.  ”***ERR0R... EXPECTING  61  LEVEL  DESCRIPTION  RECORD" 

Cause:  An  Incomplete  specification  of  all  of  the  required  level  61s 

was  made  for  either  match-key  or  phantom  pointer  relations. 

This  nonfatal  error  occurred  in  activity  3. 

Action:  Refer  to  Section  3.3  for  complete  syntax  for  level  61s.  Correct 
the  error  and  rerun  the  IDS  Analyzer. 


32.  "***ERR0R... GROUP  DECL'O  TO  HAVE  KEYS  ALONG  RELATION  IS  NOT  A MEMBER 

OF  THAT  RELATION.  GROUP- RELATION- " 

'Cause:  The  user  has  coded  a 61  level  desert ptl on  which  has  stated  that  a 

group  could  get  ' external -keys-from*  a relation  In  which  It  Is  not 
a member.  This  nonfatal  error  occurred  In  activity  4. 

Action:  Using  the  debug  output  In  the  error  message,  determine  where  in 
the  augmented  IOS  MD  section  there  appears  the  61  levels  that 
Indicated  this  group  could  get  external  keys  from  the  Indicated 
relation.  Check  to  be  sure  of  which  relatlon(s)  the  group  Is  a 
detail  and  whether  or  not  It  actually  needs  external  keys  to 
Identify  Itself  uniquely. 


R I 


33.  "***£RR0R, . .GROUP  MUST  BE  A MEMBER  OF  AT  LEAST  ONE  RELATION-  " 

Cause:  Probably  due  to  a previous  error  In  executing  the  IDS  Analyzer. 

By  the  time  activity  4 Is  executed,  the  group  specified  must  have 
been  incompletely  entered  Into  the  SDDL>  tables  by  not  attaching 
at  least  one  RELAY  record  along  the  RELMEM  set  (see  Section  5.0). 
This  nonfatal  error  occurred  in  activity  4. 

Action:  Correct  all  errors  prior  to  this  and  rerun  the  IDS  Analyzer. 

34.  "***ERR0R. .6R0UP  NOT  UNIQUE" 

Cause:  The  Analyzer  has  discovered  an  01  level  record  name  In  the  IDS 
Query  dictionary  which  Is  not  unique.  This  nonfatal  error 
occurred  In  activity  3. 

Action:  The  name  of  the  01  level  record  name  which  caused  the  error  can 
be  determined  from  the  output  which  Immediately  follows  the  error 
message.  Rename  this  01  record  and  rerun  the  Analyzer. 

35.  "***ERR0R... GROUP  WHOSE  FULL  PRIMARY  KEY  CONSISTS  OF  SOME  SET-SIG 

ITEMS  MUST  HAVE  AN  OWNER  GROUP;-  * 

Cause:  Error  In  specifying  the  EXTERNAL-KEYS-FROM  Information  for  the 

group  specified.  Relations  used  In  that  entry  are  not  relations 
for  which  the  group  Is  a detail  (member).  This  nonfatal  error 
occurred  In  activity  4. 

Action:  Check  extended  MD  section  to  ensure  that  all  Instances  of 

EXTERNAL-KEYS-FROM  entries  abide  by  the  rules  of  Section  3.5 
of  the  User  Manual . Correct  errors  and  rerun  the  IDS  Analyzer. 

36.  "***ERR0R. . .GROUP- DECLARED  TO  HAVE  KEYS  FROM  RELATION- 

DOES  NOT  HAVE  ANY  IOT1N  OWNER"  

Cause:  A group  which  had  no  primary  keys  of  Its  own  was  declared  In  a 
61  level  entry  to  have  external  key(s)  from  a master  group  which 
also  had  no  primary  key(s).  This  nonfatal  error  occurred  In 
activity  4. 

Action:  Using  the  debug  output  Information  In  the  error  message, 

determine  which  group  was  the  source  of  the  error  and  recode  the 
61  level  entries  for  that  group  making  sure  that  It  has  a valid 
primary  key  or  that  Its  owner  record  does. 


"***ERR0R. . .GROUP- 


DOESN'T  HAVE  ANY  PRIMARY  KEYS" 


Cause: 


The  group  which  Is  named  In  the  error  message  was  never  Indicated 
to  have  any  primary  keys  or  a source  of  primary  keys  In  the  61 
level  coding  for  that  group.  This  nonfatal  error  occurred  In 
activity  4. 


Action:  Find  this  group  In  the  augmented  MD  section  and  recode  the  61 
levels  making  sure  to  use  one  or  both  of  the  following  formats: 
“61  ITEMS:"  or  "61  E-K-F:". 


38.  "***ERR0R. . .GROUP- HAS  AN  OWNER  WITHOUT  A PRIM.  KEY" 

Cause:  Same  as  error  #37. 

Action:  Same  as  error  #37. 


39.  "***ERR0R... GROUP- MUST  BE  A MEMBER  OF  SOME  RELATION.  CAUSE 

DUE  TO  USER  OR  PREVHJUS'  ICS  ANALYZER  ERROR. 

Cause:  See  error  #33. 

Action:  See  error  #33. 


40.  "***ERROR... GROUP-  WAS  DECLARED  TO  HAVE  EXTERNAL  KEYS  ALONG- 

BUT  IS  NOT  A MEMBElT5F~THIS  RELATION" 

Cause:  A 61  level  "E-K-F:"  description  for  th*  group  named  in  the  error 

message  supplied  the  Analyzer  with  the  erroneous  information  that 
the  group  was  a member  of  the  named  set.  This  nonfatal  error 
occurred  in  activity  4. 

Action:  From  the  debug  output  contained  in  the  error  message,  determine 

where  in  the  augmented  MD  section  the  invalid  61  level  description 
occurred.  Be  sure  to  supply  only  relation  names  of  which  this 
group  is  a member. 


41.  "***ERR0R. . . I DENT  CAN'T  BE  SPECIFIED  FOR  IDS  DATABASES." 

Cause:  The  user  has  Inadvertently  used  a 61  level  description,  "61 

IDENT",  which  can  be  used  only  for  ISP  or  sequential  databases. 
This  nonfatal  error  occurred  in  activity  3. 

Action:  Remove  the  61  level  which  contains  the  "IDENT"  description. 


42.  "***ERR0R. . .IDENTIFICATION  FOR  RECORD  TYPE  NOT  DEFINED" 

Cause:  For  ISP  and  sequential  databases,  each  01  record  must  contain  one 

item,  denoted  by  the  61  IDENT:  clause  to  be  the  record  identifier. 
If  this  Is  not  done,  this  nonfatal  error  occurs  in  activity  3. 

Action:  Define  record  Identifiers  using  the  rules  of  Section  3.7  of  the 
User  Manual  via  the  61  IOENT  entry  and  rerun  the  IDS  Analyzer. 


"TERROR... IDS  ANALYZER  GENERATED  NAME  (ITEM-NAME/ IT)  IS  NOT  UNIQUE 
CHANGE  NAME  IN  MD  AND  61  LEVEL  SECTIONS" 


Cause:  The  Analyzer  was  unable  to  Implement  a repeating  Item  as  a 

concatenated  relation  because  It  could  not  assign  unique  names 
to  the  group  and  the  Item  within  It.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  As  the  error  message  suggests,  the  repeating  Item's  name  must  be 
changed  In  the  augmented  MD  section. 


***ERR0R... ILLEGAL  OR  MISSING  DELIMITER' 


Cause:  While  parsing  a 61  level  description,  the  Analyzer  was  unable  to 
find  the  delimiter  that  syntax  rules  would  require  given  this  61 
level  description.  This  nonfatal  error  occurred  In  activity  3. 

Action:  From  the  output  which  follows  the  error  message,  determine  which 
61  level  caused  the  error  and  Insert  the  proper  delimiter. 


***ERR0R... ILLEGAL  PAD  CHARACTER 


Cause:  The  Analyzer  was  unable  to  find  the  new  user-specified  pad  character 
In  the  61  level  description.  This  nonfatal  error  occurred  in 
activity  3. 

Action:  From  the  output  following  the  error  messaae,  determine  which  61 
level  description  containing  the  keyword  rPAD:'  caused  the  error. 

Be  sure  that  a new  pad  character  Is  supplied  following  IDS  Analyzer 
syntax  rules. 


***ERR0R... ILLEGAL  SECTION  NAME 


The  Analyzer  has  encountered  a 61  level  description  which  It 
does  not  recognize.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  In 
which  area  of  the  augmented  MD  section  the  error  occurred. 

Check  to  see  that  all  the  61  levels  In  that  area  have  valid  syntax 
and  are  logically  consistent  with  the  Analyzer  rules. 


Cause 


47.  "***ERR0R. , . ILLEGAL  SYS- ENTRY 


Cause 


An  attempt  to  override  the  Analyzer's  default  system-owned 
relation  name  generator  with  the  "SYS-ENTRY:M  61  level  description 
has  failed.  The  reason  Is  either:  1)  "SYS-ENTRY”  syntax  was 
violated;  or  2)  the  record  Is  not  on  a CALC  or  primary  chain.  This 
nonfatal  error  occurred  In  activity  3. 


Action:  Using  the  output  which  1 mediately  follows  the  error  message, 

determine  which  61  level  description  was  the  source  of  the  error. 
Check  to  see  that  all  syntax  rules  were  followed  and  that  the 
record  Is  a member  of  a CALC  or  primary  chain. 


N***ERR0R. . . IMPOSSIBLE  TO  OPEN  08- 


IERR- 


Cause:  One  of  the  two  A06MS  databases  used  by  the  Analyzer  cannot  be 

opened  for  access.  This  Is  probably  a control  card  error;  data- 
bases must  be  random,  the  size  must  be  at  least  1 link.  This 
fatal  error  occurred  In  activity  3. 

. r 

Action:  Contact  the  Data  Translation  Project  If  control  cards  are  correct. 

49.  "***ERR0R. . . IN  MATCH-KEY  RELATIONS , EXPECTING  WORD- ' KEY ' " 

Cause:  The  Analyzer  has  detected  a syntax  error  while  processing  61 

levels  describing  a match-key  relation.  The  next  61  level  should 
have  been:  "61  KEYS:".  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  at  which 
61  level  the  Analyzer  detected  the  error  and  Insert  the  61  level 
coding  as  described  In  Section  3.6.1. 

50.  "***ERR0R... INVALID  DEPENDENT  NAME  FOR  PHANTOM  RELATION" 

Cause:  While  processing  61  level  entries  which  describe  a phantom  pointer 
relation,  the  Analyzer  was  unable  to  find  the  name  of  the  dependent 
In  the  relation.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  at  which 
61  level  the  Analyzer  detected  the  error  and  Insert  the  proper 
61  level  coding  as  described  In  Section  3.6.2. 

51 . "***ERR0R. . . INVALID  NAME  FOR  PHANTOM  RELATION. " 

Cause:  While  processing  61  level  entries  which  describe  a phantom  pointer 
relation,  the  Analyzer  was  unable  to  find  the  name  of  the  relation 
following  the  61  level:  "61  RELATION:".  This  nonfatal  error 
occurred  In  activity  3. 

Action:  Same  as  error  #50. 

52.  "***ERR0R... INVALID  POINTER  NAME  FOR  PHANTOM  RELATION" 

Cause:  While  processing  61  level  entries  which  describe  a phantom  pointer 
relation,  the  Analyzer  was  unable  to  find  the  name  of  the  Item 
to  be  used  as  a pointer  following  the  61  level:  "61  POINTER:". 

This  nonfatal  error  occurred  In  activity  3. 


Action: 


53.  "***ERR0R. . . INVALID  51  LEVEL  DESCRIPTION. M 

Cause:  While  processing  61  level  descriptions  which  followed  "02 

TRANSLATION  INFORMATION  SIZE  0",  the  Analyzer  encountered  a 61 


level  which  1$  not  correct  given  the  context  in  which  it  appears. 
This  nonfatal  error  occurs  in  activity  3. 

Action:  Using  the  output  following  It,  determine  which  61  level  generated 
the  error  message.  It  is  possible  that  the  error  vts  Initiated 
by  the  61  level  coding  Immediately  preceding  the  current  61 
level.  Therefore,  make  sure  that  the  last  few  61  levels  reflect 
the  user's  Intent  and  follow  Analyzer  syntax  rules. 


54.  "***ERR0R. . . ITEM  WITH  DBKEY  (SEE  DUMP  REPORT)  OF- DECL'D  TO 

BE  PRIMARY  KEY  MORE  THAN  ONCE  MULTIPLE  DECLARATI0NS~T5N0RED" 

Cause:  The  user  has  specified  an  item  as  a primary  key  of  a record  more 
than  once  in  the  61  level  description,  "61  PRIMARY-KEYS:".  This 
nonfatal  error  occurred  In  activity  4. 

Action:  None  necessary. 


55.  "***ERR0R... KEYWORD  'DEPENDENT'  EXPECTED" 

Cause:  While  processing  61  levels  describing  match-key  or  phantom  pointer 
relations,  the  Analyzer  expected  the  61  level  "61  DEPENDENT:" 
to  appear  next  but  did  not  find  It.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  at  which 
61  level  the  error  occurred  and  Insert  the  correct  61  level 
description  as  described  In  Section  3.6.2  for  phantom  pointers,  or 
Section  3.6.1  for  match-key  relations. 


56.  "***ERR0R. . . KEYWORD  ' PARENT'  NOT  FOUND" 

While  processing  61  levels  describing  match-key  relations,  the 
Analyzer  expected  the  61  level  "61  PARENT:"  to  appear  next  but 
did  not  find  It.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  at  which 
61  level  the  error  occurred  and  Insert  the  correct  61  level 
description  as  described  In  Section  3.6.1  for  match-key  relations 


Cause 


57.  M***ERROR... LENGTH  OF  NAME  OVER  30  CHARACTERS" 

Cause:  The  user  has  specified  a group.  Item,  or  relation  name  which  Is 
greater  than  30  characters  long  In  the  augmented  IDS  MO  section. 

This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine 

where  In  the  MO  section  the  error  occurred  and  change  the  name 
to  one  less  than  or  equal  to  30  characters  In  length. 

58.  "***ERR0R... LOOPS  OF  PRIMARY  KEYS  MUST  HAVE  BEEN  DEFINED  BY  THE  USER. 
CHECK  TO  SEE  THAT  PRIMARY  KEYS  FOR  ANY  GROUP  AREN'T  MADE  UP  OF  PRIMARY 
KEYS  THAT  THE  GROUP  GENERATES  TO  ITS  MEMBERS.  APPLY  THIS  RECURSIVELY." 

Cause:  A basic  IDS  Analyzer  rule  has  been  violated.  A circular  path, 
describing  where  groups  get  primary  keys  has  been  defined  in  the 
61  levels.  This  nonfatal  error  occurred  In  activity  4. 

Action:  Refer  to  the  debugging  report  which  follows  the  error  message. 

61  levels  which  propagated  the  error  must  be  recoded. 

59.  "***ERR0R... MATCH-KEY  ITEM  NOT  DEFINED  IN  PARENT" 

Cause:  The  Item  specified  by  the  user  as  a match-key  Item  In  the  parent 

of  the  relation  Is  not  an  Item  which  appears  In  the  parent.  This 
nonfatal  error  occurred  in  activity  3. 

tlon:  Recode  the  61  level  entry  "61  KEYS:",  so  that  the  key  Item 

specified  Is  a valid  Item  within  the  parent.  The  61  level  which 
caused  the  error  can  be  determined  from  the  output  which  follows 
the  error  message. 

60.  "***ERR0R. . . PHANTOM  RELATIONS  CANNOT  BE  USED  FOR  ISP  OR  SEQ  DATABASES" 

Cause:  The  user  has  attempted  to  Implement  a phantom  pointer  relation  In 
an  ISP  or  sequential  database.  This  nonfatal  error  occurred  In 
activity  3. 

Action:  Because  this  Is  prohibited  by  the  IDS  Analyzer,  the  user  should 
remove  the  61  level  coding  relevant  to  the  error  and  Implement 
the  desired  relationship  In  another  acceptable  way. 

61 . "***ERR0R. . .MISPLACED.EOG.  STATEMENT. " 

Cause:  The  Analyzer  has  detected  a 61  level  'END  OF  6R0UP'  description 

which  Is  out  of  context  based  on  the  preceding  61  level  descriptions. 
This  nonfatal  error  occurred  In  activity  3, 

Action:  Inspect  the  output  which  follows  the  error  message  to  determine 
which  61  level  contains  the  misplaced  EOG.If  It  Is  extraneous,  or 
rewrite  the  61  level  descriptions  to  follow  IDS  Analyzer  syntax 
rules  as  described  In  Section  3.3. 


***ERROR. . .MISSING  PRIME" 

Correct  61  level  syntax  In  this  situation  caused  the  Analyzer  to 
look  for  a prime  (').  This  nonfatal  error  occurred  In  activity 


Action 


From  the  output  which  follows  the  error  message  and  the  Intent 
of  the  user  In  coding  It,  determine  which  61  level  caused  the  error. 
Refer  to  the  syntax  rules  covering  this  situation  to  determine  where 
the  prime  Is  to  be  placed. 


***EAR0R...M0RE  THAN  5 DATA  BASES  ENTERED  IN  PARAM.  FILE 


Cause:  The  user  specified  more  than  five  database  names  In  the  parameter 
file.  This  nonfatal  error  occurred  in  activity  3. 

Action:  The  IDS  Analyzer  restricts  the  number  of  databases  on  which  it 

will  work  to  five.  In  order  to  use  the  Analyzer  module,  the  user 
should  observe  this  limitation. 


64.  "***ERR0R. . .NAME  IN  CLAUSE  MUST  BEGIN  WITH  LETTER  OR  DIGIT" 

Cause:  User  name  must  begin  with  a letter.  Constants  must  begin  and 

consist  entirely  of  digits.  Violation  results  In  this  nonfatal 
error  which  occurs  In  activity  3. 

Action:  Rewrite  offending  user  name  or  constant  and  rerun  the  IDS  Analyzer 


65.  "***ERR0R. . .NAME  OF  RELATION  IS  NOT  UNIQUE" 

Cause:  The  name  of  the  relation  supplied  by  the  user  to  be  used  In 

a match-key  relation  Is  not  unique.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  the 
location  of  the  61  level  containing  the  non-unique  relation 
none.  Change  the  relation  name. 


66,  "***ERR0R, , . NO  DATA  BASES  SPECIFIED  IN  PARAM.  FILE" 

Cause:  After  reading  the  entire  parameter  file,  the  Analyzer  was  unable 
to  find  the  name  of  any  database.  This  fatal  error  occurred  In 
activity  3. 

Action:  Check  the  paraneter  file  to  be  sure  that  the  name  of  the  user‘s 

database  Is  specified  according  to  the  rules  stated  In  Section  5.6 
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67.  "***ERROR. . .NO  DELIMITER  FOUND1* 

0 

Cause: 

The  Analyzer  expected  to  find  a legal  delimiter  but  could  not. 

This  nonfatal  error  occurred  In  activity  3. 

0 

n 

Action: 

Inspect  the  output  following  the  error  message  to  determine 

In  which  61  level  the  Analyzer  expected  to  find  a delimiter. 

Make  sure  the  syntax  Is  consistent  with  the  user's  Intent 
and  the  IDS  Analyzer  syntax  rules. 

68.  "***ERROR. ..NO  GROUPS  DEFINED  IN  DATABASE"  j 

Cause: 

The  IDS  Analyzer  failed  to  generate  any  groups  In  the  SDDL  tables. 

This  nonfatal  error  occurred  In  activity  4. 

1 ) 

Action: 

This  error  will  not  occur  without  other  errors  preceding  It. 

Correcting  these  errors  should  eliminate  this  one. 

0 

69.  "***ERR0R...N0  ITEM  RECORDS  ARE  PRESENT  ON  THE  ITEM  SET  IN  THE  SDDL 

TABLES  FOR  THE  CURRENT  GROUP” 

0 

B 

Cause: 

While  attempting  to  determine  If  an  Item  specified  by  the  user  as 
a key  of  a group  Is  actually  an  Item  within  that  group,  the  Analyzer 
discovered  that  the  group  has  no  Items.  This  nonfatal  error  occurred 

In  activity  3. 

i, 

Action: 

This  error  can  occur  only  as  a result  of  prior  errors.  If,  after 
correcting  all  prior  errors,  this  message  still  appears,  contact 
the  Data  Translation  Project. 

1 

1 

70.  No  longer  Implemented 

1 

71.  "***ERR0R. . .NUMBER  OF  MATCH-KEYS  IN  PARENT  NOT  * TO  NUMBER  OF  MATCH- 
KEYS  IN  DEPENDENT" 

Q 

Cause: 

In  defining  a match-key  relation  In  the  61  levels,  the  user 

mismatched  the  nunber  of  match-keys  In  the  parent  and  the  depen-  J 

dent.  This  nonfatal  error  occurred  In  activity  3. 

0 

0 

Action: 

Determine  where  the  match-key  relation  Is  defined  In  the  augmented 

MD  section  by  examining  the  output  following  the  error  message. 

Change  the  61  level  coding  so  that  the  numbers  of  match-keys  In  the 
parent  and  the  dependent  are  equal . 

o 

72.  ”***ERROR. . . NUMBER  OF  OCCURRENCES  IS  ZERO” 

li 

Cause: 

User  specified  OCCURS  0 TIMES  In  level  61  entry.  This  nonfatal 
error  occurred  In  activity  3. 

11 

0 

Action: 

Groups  must  occur  at  least  once.  Rewrite  the  level  61  entry 
according  to  rules  In  Section  3.3  and  rerun  the  IDS  Analyzer. 

At!  6 
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73.  "***ERROR. . .PARENT  OF  MATCH-KEY  RELATION  IS  NOT  DEFINED* 

Cause:  The  name  of  the  group  which  the  user  specified  as  the  parent  In 

a natch-key  relation  does  not  exist.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  Using  the  output  following  the  error  message,  determine  where  the 
Analyzer  was  In  the  augmented  IDS  MD  Section  when  the  error  was 
<’'“.«cted.  Replace  the  name  of  the  parent  group  with  a valid  one 
-dance  with  the  rules  set  forth  In  Section  3.6.1. 


7*.  . J1T0M  RELATION  NAME  NOT  UNIQUE* 

. :o '•  1 t 

Car.se:  The  name  of  the  phantom  relation  supplied  by  the  user  Is  not 

unique  to  this  augmented  MD  section.  This  nonfatal  error  occurred 
In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  which 
61  level  contains  the  nonunique  relation  name  and  change  It. 


75.  "***ERR0R...* POINTER'  NOT  FOUND" 

Cause:  The  syntax  rules  for  coding  61  levels  to  define  phantom  pointer 
relations  require  the  key  word  'POINTER*  which  the  Analyzer  was 
unable  to  find.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  where 
In  the  MD  section  the  phantom  pointer  relation  was  defined.  Make 
sure  that  the  syntax  rules  of  Section  3.6.2  are  obeyed. 


76.  "***ERR0R..  .RELATION- DOESN'T  HAVE  A MEMBER  GROUP" 

Cause:  Previous  error  In  IDS  Analyzer.  Detail  (member)  of  either  a chain, 

match-key,  or  phantom  relation  does  not  exist.  This  nonfatal  error 
occurred  In  activity  4. 

Action:  . Correct  all  previous  errors  and  rerun  IDS  Analyzer. 


77.  "***ERR0R. ..SIZE  COITLICT  BETWEEN  LENGTH  OF  GROUP  AND  LENGTHS  OF 
ELEMENTARY  ITEMS" 

Cause:  A group  of  size  "x"  has  been  defined  In  the  IDS  MO  section,  but 

the  sue  of  Its  elementary  Items  Is  not  equal  to  Its  declared  size. 
This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  where 
In  the  augmented  IDS  MD  section  the  error  occurred.  Following  the 
rules  set  forth  In  Section  3.2.1,  recalculate  the  length  of  the 
group. 
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78.  "***ERROR. . .SYMBOL  DEFINED  IN  61  LEVELS  IS  NOT  IN  THE  IDS  HD  SECTION, 
SYMBOL  IS:  ■ 


D 

0 

0 


Cause:  The  user  specified  a Match-key  Item,  phantom  pointer  Item,  or 

dependent  group  nane  within  level  61  entries  for  which  there  Is  no 
occurrence  within  the  IDS  MD  section.  The  most  likely  cause  Is 
misspelling.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Correct  erroneous  level  61  entry  where  the  "symbol"  appears  and 
rerun  the  ID5  Analyzer. 


79.  "***ERR0R. . .SYNTAX  OF  I DENT  CLAUSE  IS  INCORRECT" 

Cause:  The  Analyzer  was  unable  to  successfully  parse  through  the  61  level 
description  being  used  to  define  an  IDENT  Item  for  the  current 
record.  This  nonfatal  error  occurred  In  activity  3. 

Action:  Using  the  output  which  follows  the  error  message,  determine  at 

which  61  level  the  error  occurred  and  rewrite  It  to  follow  correct 
syntax  rules. 


80.  "***ERR0R... THERE  IS  NO  NEXT  POINTER  FOR  MD" 

Cause:  Query  dictionary  was  Incorrectly  built  by  IDS  Translator  In  query 
mode.  Each  Master  Definition  record  has  a field  within  It  con- 
taining the  displacement  of  the  next  pointer  for  the  chain.  If 
this  field  Is  zero,  the  above  nonfatal  error  occurs  In  activity  3. 

Action:  Check  extended  IDS  MD  section  closely  to  ensure  that  all  98  chain 
CHAIN  MASTER  entries  are  correctly  written.  Refer  to  the  IDS 
Programmer's  Guide  for  complete  syntax  rules. 


81 . "***ERR0R. . .TOO  MANY*  02  LEVaS  MAX  » 50" 

Cause:  Internal  tables  In  the  IDS  Analyzer  can  handle  only  50  02  levels 

per  01  record.  This  fatal  error  occurred  In  activity  2, 

Action:  Change  the  MD  section  to  have  fewer  than  50  02  levels  If  It  Is  a 
target  MD;  otherwise,  contact  the  Data  Translation  Project. 
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82.  "***ERR0R... UNABLE  TO  SET  CURRENCY  OF  HASPK  AND  EXKEYS  SETS.  NO  GRP 
RECORD  TO  MATCH  USER  SUPPLIED  GROUP  NAME." 

Cause:  This  error  can  occur  only  as  a result  of  previous  errors  or 
program  logic  faults.  It  Is  a nonfatal  error  which  occurs  In 
activity  3. 

Action:  If,  after  all  previous  errors  have  been  corrected,  this  error  still 
remains,  contact  the  Data  Translation  Project. 


83.  "***ERROR. . . USER  COOED  MULTIPLE  TRANSLATION  INFORMATION ' S . 61 
LEVELS  IGNORED  EXCEPT  UNDER  1ST  OCCURRENCE" 

Cause:  The  02  level,  "02  TRANSLATION-INFORMATION  SIZE  0"  has  occurred 
more  than  once  under  the  same  01  record.  This  nonfatal  error 
occurs  In  activity  3. 

Action:  Remove  the  redundant  "02  TRANSLATION-INFORMATION  SIZE  0".  Its 
location  can  be  determined  by  examining  the  output  which  follows 
the  error  message. 


84.  "***ERR0R. . .USER  DEFINED  MORE  THAN  75  GROUPS,  VECTORS  FOR  BLDKY 

MUST  BE  REDIMENSIONED.” 

Cause:  An  Internal  Analyzer  table  overflowed  because  the  user  specified 
more  than  75  groups  In  the  augmented  NO  section.  This  fatal  error 
occurred  In  activity  4. 

Action:  Although  this  error  will  not  terminate  execution.  It  probably 
will  propagate  further  errors.  Contact  the  Data  Translation 
Project  If  the  problem  occurred  In  a source  MD  section.  Otherwise, 
reduce  the  MD  to  less  than  75  groips.  If  possible. 


85.  "***ERR0R. . . USER  HAS  SPECIFIED  AN  INVALID  GROUP  NAME." 

Cause:  The  name  of  the  group  supplied  by  the  user  In  the  "Primary-Keys1 


section  does  not  exist 


nonfatal  error  occurred  In  activity  3. 


Action:  Determine  which  61  level  description  contained  the  Invalid  group 
name  by  Inspecting  the  output  which  follows  the  error  message. 
Replace  the  Incorrect  name  with  one  which  Is  consistent  with  the 
rules  stated  In  Section  3.5. 


86.  "***ERROR...USER  HAS  SPECIFIED  AN  INVALID  ITEM  AS  A PRIMARY  KEY" 

Cause:  The  Item  named  by  the  user  to  be  a primary  key  of  a group  Is  not 
an  Item  belonging  to  that  group.  This  nonfatal  error  occurred  In 
activity  3. 

Action:  Determine  from  the  output  which  follows  the  error  message  which 

61  level  description  contains  the  source  of  the  error.  Delete  the 
Invalid  Item's  name  and  make  sure  that  all  other  Items  declared 
as  keys  for  the  group  actually  are  Items  within  that  group. 


87.  "***ERR0R. . .USER  SYNTAX  IS  WRONG" 

Cause:  The  Analyzer  Is  unable  to  Interpret  the  current  61  level  given  the 
context  In  which  It  appears.  This  nonfatal  error  occurred  In 
activity  3. 
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Action:  Determine  from  the  output  that  follows  the  error  message  which 
61  level  generated  the  error  message  and  check  that  61  level • as 
well  as  several  others  before  It,  to  make  sure  that  all  relevant 
syntax  rules  are  obeyed. 


88.  "***ERROR...*****DATABASE  FOR  SDDL  TABLES  IS  TOO  SMALL,  ACTIVITY 
TERMINATED.” 

Cause:  This  error  message  Is  preceded  by  error  message  #9.  The  error 
occurred  because  the  Analyzer's  supporting  database  management 
system,  ADBMS,  has  run  out  of  room  In  the  database  which  holds  the 
SDDL  tables.  This  Is  ADBMS  error  #17.  It  Is  a fatal  error  which 
occurred  In  activity  4. 

Action:  Recreate  the  SDDL  tables  database  to  a larger  size  and  rerun  the 
Analyzer. 


89.  "***MARNING...SET-SIG  ITEM  NAME  FOR-  TRUNCATED  ON  RIGHT  TO 
240  CHARS" 

Cause:  A set-significant  Item  name  was  generated  with  a length  greater 

than  240  characters,  the  upper  limit  allowed.  Truncation  occurred 
J to  trim  It  to  240  characters.  This  nonfatal  error  occurred  In 

activity  4. 


Action:  No  action  Is  necessary.  This  message  Is  generated  simply  to 
r | alert  the  user  to  the  fact  that  some  set-significant  Item  names 

may  have  an  unusual  appearance  due  to  the  truncation. 


gO.  "*******ERR0R  IN  NAMFXS *******" 

Cause:  An  Analyzer  support  routine  was  unable  to  generate  a needed  name. 

The  user  specified  more  than  twenty  Items  within  one  record  whose 
first  six  characters  are  Identical  or  there  are  more  than  twenty] 
record  or  relations!  whose  names  have  Identical  first  six  characters. 
This  nonfatal  error  occurred  In  activities  3 and  4. 

Action:  Change  user  names  so  that  first  six  characters  of  records, 
relations,  and  Items  are  not  Identical. 


APPENDIX  8 
TDL  ANALYZER  ERRORS 

Activity  1 Errors 


Activity  1 Is  an  execution  of  the  system  UTILITY  routines.  A description 
of  the  errors  generated  can  be  found  In  the  UTILITY  manual. 

Activity  2 Errors 

1.  ANALYZER  ERROR,  STACK  OVERFLOW 

Cause:  The  error  recovery  procedure  was  not  able  to  recover  properly. 

Action:  Correct  any  previous  errors. 

2.  MACRO  LITERAL  TRUNCATED  TO  ONE  LINE 

Cause:  The  literal  portion  of  a macro  declaration  exceeded  one  line. 

This  Is  a warning. 

Action:  Make  sura  that  the  macro  literal  begins  and  ends  on  the  same 
line.  If  the  macro  literal  Is  more  than  one  line  long,  then 
several  literals  may  be  needed. 

3.  MACRO-NAME  INSIDE  OF  MACRO,  IGNORED 

Cause:  A macro  name  was  found  Inside  the  macro  literal.  This  Is  a warning. 
Action:  Remove  Imbedded  macro  names. 

4.  SYNTAX  ERROR,  ILLEGAL  TOKEN  PAIR 

Cause:  A user  syntax  error.  This  Is  a nonfatal  error. 

Action:  Remove  the  syntax  error. 
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5.  SYNTAX  ERROR,  NO  PRODUCTION  MATCHES 
Cause:  A nonfatal  user  syntax  error. 
Action:  Remove  the  syntax  error. 
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6.  ERROR  RECOVERY  PROCEOURE  BEGINNING 

Cause:  A previous  syntax  error  has  caused  the  error  recovery  procedure 
to  begin.  This  Is  a warning. 

Action:  Remove  the  previous  syntax  error. 


7.  ERROR  RECOVERY  PROCEOURE  COMPLETED 

Cause:  A previous  syntax  error  Initiated  the  error  recovery  procedure 
which  Is  now  complete.  Lines  between  the  "beginning"  and  the 
"completed"  error  recovery  procedure  warning  messages  were  not 
processed.  This  Is  a warning. 

Action:  Remove  the  previous  syntax  error. 


8.  EOF  FOUND,  SECTION  COMPILING  STOPPED 

Cause:  A previous  syntax  error  Initiated  the  error  recovery  procedure 
which  could  not  recover  before  the  end-of-flle  was  reached. 
This  Is  a nonfatal  error. 

Action:  Remove  the  previous  error. 


9.  ANALYZER  ERROR,  R-W  TABLE  OVERFLOWED 
Cause:  A fatal  error  In  the  TDL  Analyzer. 

Action:  Ensure  that  the  TDL  parse  tables  are  connected  to  the  correct 
I/O  unit. 


10.  ILLEGAL  R.W.  - ENTERED  AS  USER  NAME 

Cause:  This  nonfatal  error  should  appear  only  In  future  Implementations 
of  the  TDL  Analyzer. 

Action:  Contact  the  Data  Translation  Project. 

11.  ANALYZER  ERROR,  SYM  TABLE  OVERFLOW 

Cause:  Too  many  user  names  and  macros  were  entered;  the  symbol  table 
has  overflowed.  This  Is  a fatal  error. 

Action:  Recompile  the  TDL  Analyzer  with  a larger  BLOCK  DATA. 


12.  MACRO  MUST  BE  FOLLOWED  BY  A NAME 

Cause:  The  macro  name  Is  missing  In  the  macro  definition.  This  Is  a nonfatal 
error. 

Action:  Correct  the  macro  definition  syntax  error. 


13.  NAME  PREVIOUSLY  USED  - MACRO  IGNORED 

Cause:  The  macro  name  was  previously  used.  This  Is  a nonfatal  error. 
Action:  Select  a new  macro  name. 


14.  LITERALLY  SHOULD  FOLLOW  MACRO-NAME 

Cause:  Improper  macro  definition  syntax.  This  Is  a warning. 

Action:  Correct  the  syntax  error. 


15.  A LITERAL  MUST  FOLLOW  "LITERALLY" 

Cause:  Improper  macro  definition  syntax.  This  Is  a nonfatal  error. 
Action:  Correct  the  syntax  error. 

16.  SEVERE  ERROR(S) , MACRO  NOT  ENTERED 

Cause:  Previous  errors  have  caused  the  macro  definition  to  be  Ignored. 

This  Is  a nonfatal  error. 

Action:  Correct  the  previous  errors. 

17.  ANALYZER  ERROR,  FREE  AREA  OVERFLOWED 

Cause:  Too  many  user  names  and  macro  names  were  entered.  This  Is  a 
fatal  error. 

Action:  Recompile  the  TDL  Analyzer  with  a larger  block  data. 

18.  ANALYZER  ERROR,  FREWRD  OVERFLOWED 

Cause:  Too  many  user  names  and  macro  names  were  entered.  This  Is  a 
fatal  error. 

Action:  Recompile  the  TDL  Analyzer  with  a larger  block  data. 


19.  ILLEGAL  CHARACTERS  IN  INPUT,  IGNORED  . 

Cause:  Illegal  characters  appeared  In  the  Input  stream.  This  Is  a 

warning. 

Action:  Remove  the  Illegal  characters. 


20.  NAMELENGTH  > 256,  WILL  BE  TRUNCATED 

Cause:  The  user  name  Is  more  than  256  characters  long.  This  Is  a warning 
Action:  Change  the  user  name. 


21.  INTEGER  OVERFLOW,  VALUE  TRUNCATION 

Cause:  The  Integer  has  exceeded  Its  maximum  value.  This  Is  a warning 
Action:  Change  the  Integer. 


22.  LITERAL  LENGTH  > 256,  WAS  TRUNCATED 

Cause:  The  literal  Is  more  than  256  characters  long.  This  Is  a warning 
Action:  Change  the  literal. 


23.  LITERAL  DOES  NOT  END  WITH  A PRIME 

Cause:  The  closing  prime  for  the  literal  Is  missing.  This  Is  a warning 
Action:  Correct  the  syntax. 


24.  COWENT  DOES  NOT  TERMINATE  WITH  A */ 

Cause:  A comment  was  not  enclosed  by  /*  and  */>  This  Is  a warning 


Action:  Correct  the  syntax  error 


25.  EOF  MISSING,  EOF  CARD  INSERTED 


Cause:  The  last  card  processed  was  not  an  EOF  card.  This  Is  a warning 
Action:  Insert  an  EOF  card  after  the  last  card. 


26.  TARGET  RECORD  NOT  FOUND 

Cause:  The  target  record  with  the  specific  name  does  not  exist.  This  Is 


irget 

a nonfatal  error. 


Action:  Check  the  target  SDDL  table  dump  (part  of  the  IDS  Analyzer  output) 
to  ensure  that  the  target  record  name  used  In  the  TDL  description 
Is  correct. 
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33.  SET  SI6  ITEMS  CANNOT  BE  ASSIGNED 

Cause:  A source  set-significant  Item  was  used  In  a TDLAP  where  ACCEPT 
IF  NULL  was  specified  for  one  or  more  of  the  source  records. 

This  Is  a nonfatal  error. 

Action:  Alter  the  TDLAP  so  that  all  assignments  and  qualifications  refer 
only  to  actual  Items. 


34.  SOURCE  ITEM  NOT  FOUND 

Cause:  The  source  Item  does  not  exist  In  the  specified  source  record. 

This  Is  a nonfatal  error. 

Action:  Check  the  source  SDDL  table  dump  (part  of  the  IDS  Analyzer  output) 
to  ensure  that  the  source  Item  name  In  the  TDL  description  Is 
correct. 


35.  QUALIFICATION  LINK  NAME  TRUNCATED 


Cause:  The  qualification  link  name  Is  more  than  six  characters  long 
This  Is  a nonfatal  error. 

Action:  Correct  the  link  name. 


36.  INVALID  ID  FOR  RECORD 

Cause:  The  specified  ID  does  not  match  the  record  given.  This  Is  a 
nonfatal  error. 

Action:  Check  the  source  record  and  ID  to  determine  which  Is  In  error 


37.  FROM  SOURCE  RECORD  NOT  FOUND 

Cause:  The  "from"  source  record  has  not  yet  been  placed  on  the  access 
tree  (TDLAP).  This  Is  a nonfatal  error. 

Action:  Check  to  see  that  the  correct  record  name  and  relation  name 
were  used.  Then  make  sure  that  the  "from"  source  record  was 
previously  placed  on  the  DTLAP.  The  ordering  of  source  record 
may  need  to  be  altered. 

38.  CONVERSION  LINK  NAME  TRUNCATED 

Cause:  The  conversion  link  name  Is  more  than  6 characters  long.  This 
Is  a nonfatal  error. 

Action:  Use  the  correct  link  name. 


39.  NULL  VAL  ILLEGAL  W/0  ACCEPT  IF  NULL 


0 


Cause:  A null  value  was  specified  for  a target  Item  and  Reject  IF  NULL 
was  specified  {or  defaulted)  for  the  source  record. 

Action:  Determine  whether  the  source  record  should  be  ACCEPTed  or  REJECTed 
If  null.  If  ACCEPT  IF  NULL,  this  adds  this  clause  to  the  source 
record  statement.  If  REJECT  IF  NULL,  then  remove  the  NULL  VALUE 
clause(s). 


40.  NO  ACTUAL  DATA  TO  ASSIGN 

Cause:  The  user  specified  ACTUAL  DATA  IN  ORDER  when  no  actual  data  exists. 
This  Is  a warning. 

Action:  None  required;  however,  be  aware  of  the  fact  that  no  actual  data 
has  been  assigned. 


41.  ACTUAL  DATA  TOO  BIG  FOR  TARGET  RECORD 

Cause:  The  user  specifies  ACTUAL  DATA  IN  ORDER  for  a source  record  which 
contains  more  data  than  will  fit  In  that  target  record.  This  Is 
a nonfatal  error. 

Action:  Use  explicit  Item  assignments  Instead  of  ACTUAL  DATA  IN  ORDER. 


42.  SET  SIG  ITEMS  CANNOT  BE  ASSIGNED 

Cause:  Set-slgnlf leant  source  Items  were  used  on  a TDLAP  where  ACCEPT 

IF  NULL  was  specified  for  one  of  the  source  records.  This  Is 
a nonfatal  error. 

Action:  Alter  the  TDLAP  so  that  all  assignments  and  qualifications  are 
based  on  actual  source  Items. 


43.  CONFLICTING  SOURCE  RECORD  AND  ACCESS 

Cause:  The  source  record  Is  not  a member  or  an  owner  of  the  access  via 
relation.  This  Is  a nonfatal  error. 

Action:  Check  the  source  SODL  table  dump  (part  of  the  IDS  Analyzer  output) 
to  ensure  that  the  source  record  name  In  the  TDL  description  Is 
correct. 


44.  OWNER/MEMBER  OR  MEM/OWN  MUST  BE  USED 

Cause:  The  source  record  Is  both  the  owner  and  the  member  of  the  relation. 
This  Is  a nonfatal  error. 

Action:  Determine  If  the  record  should  be  the  owner  or  member  of  the 
relation  and  Insert  an  OWNER/MEMBER  or  a MEMBER/OWNER  clause. 


45.  NO  NODE  TO  ATTACH  SOURCE  RECORD  TO 


Cause:  The  source  record  at  the  other  end  of  the  access  via  relation  Is 
not  a node  In  the  current  TDlAP.  This  Is  a nonfatal  error. 

Action:  Ensure  that  the  correct  access  via  relation  was  used  and  that  the 
TDLAP  tree  nodes  are  constructed  from  root  to  leaves. 

46.  OUNER/MEMBER  OR  MEM/OHN  INCORRECT 

Cause:  Owner/momber  was  specified  when  member/owner  Is  actually 
correct,  or  vice  versa.  This  Is  a nonfatal  error. 

Action:  Ensure  that  source  record  and  access  via  relations  are  correct 
and  change  owner/member  to  nenber/owner  or  vice  versa. 

47.  NODE  ALREADY  EXISTS  ON  ACCESS  TREE 

Cause:  A source  record  has  been  placed  on  the  TDLAP  more  than  once. 

This  Is  a nonfatal  error. 

Action:  Ensure  that  duplicate  nodes  on  the  TDLAP  are  desired. 

48.  ID  MANDATORY  FOR  THIS  SOURCE  RECORD 

Cause:  The  source  record  needs  an  ID  to  uniquely  Identify  It.  This  Is 
a nonfatal  error. 

Action:  Add  an  ID  * clause  to  the  source  record. 

49.  ID  AND  SOURCE  RECORD  NAME  CONFLICT 

Cause:  The  source  record  with  the  ID  specified  does  not  have  the  same 

name  as  the  source  record  name  specified.  This  Is  a nonfatal  error. 

Action:  Determine  which  source  record  Is  desired  and  change  the  ID  and/or 
source  record  specified. 

50.  QUALIFICATION  ITEM  NOT  FOUND  v . 

Cause:  The  qualification  Item  does  not  exist  In  the  specified  source 
group.  This  Is  a nonfatal  error. 

Action:  Determine  the  source  record  where  the  qualification  Item  exists 
and  add  or  correct  the  From  clause. 


51 . TOL  DATA  BASE  TOO  SMALL  or  PREVIOUS  ERRORS  OR  ERRORS  IN  THE 
SDDL  TABLES  HAVE  CAUSED  A FATAL  ERROR. 

Cause:  Either  the  TOL  database  file  Is  not  large  enough  or  an  unreasonable 
error  has  occurred. 


Action:  Recreate  the  TDL  tables  with  a larger  size.  Check  the  IDS  Analyzer 
output  to  ensure  that  no  errors  occurred  and  correct  any  errors  en- 
countered In  the  partial  run  of  the  TDL  Analyzer. 


Activity  3 Errors 

ERROR  ENCOUNTERED  WHILE  SETTING  SYSACCS 


Action:  Contact  the  Data  Translation  Project 


Activity  4 Errors 
ERROR  IN  CONSTRUCTION  OF  COMPATIBILITY  SETS 


Action:  Contact  the  Data  Translation  Project 


Activity  5 Errors 

1.  TDL  TABLE  INCONSISTENCY  OR  TDL  DUMP  PROGRAM  ERROR 


Action 


This  Is  a fatal  error.  Any  errors  found  In  activity  2 should  be 
corrected.  If  no  activity  2 errors  were  detected,  then  contact 
the  Data  Translation  Project. 


APPENDIX  C 
READER  ERRORS 


These  error  messages  are  found  on  report  code  06  Activity  2 (Activity 
3 for  the  IDS  Reader). 

1.  ###ERR0R ACCIDS  HAS  AN  IOS  ERROR. 

Cause:  An  IDS  error  (not  abort)  has  occurred  In  the  Accessor  module. 

Action:  Make  sure  the  proper  MD  section  was  compiled  with  the  Accessor. 
Check  the  IDS  compilation  for  errors. 


2.  ###ERR0R ACCISP  HAS  AN  ISP  ERROR. 

Cause:  An  ISP  error  has  occurred  In  the  Access or  module. 

Action:  Be  sure  the  ISP  database  Is  In  the  proper  order.  An  error 
explanation  will  probably  be  In  the  execution  report  ($$). 

3.  ###ERR0R ADBMS  ERROR  IN  FILLIT. 

Cause:  An  error  condition  has  arisen  In  the  Internal  database  management 
system. 

Action:  This  error  message  will  precede  an  ADBMS  error  message  and  trace 
(see  Appendix  F for  an  explanation  of  ADBMS  errors).  If  the  error 
Is  #17  and  the  HDB*2"  then  Increase  the  size  of  the  source  RIF 
and  rerun  the  Reader.  If  the  error  Is  #17  and  the  "DB»3",  then 
Increase  the  size  of  DRT  file  and  rerun  the  Reader.  Otherwise, 
this  error  can  be  corrected  only  by  Data  Translation  personnel. 

4.  ###ERR0R..... CALL  TO  NXTITM,  NO  CURRENT  GROUP. 

Cause:  There  Is  no  current  group  In  the  SDDL  tables. 

Action:  This  Indicates  a serious  error  has  occurred  In  the  logic  of  the 

Reader.  It  will  probably  be  preceded  by  other  errors  which  should 
be  corrected  first.  Otherwise,  It  can  be  corrected  only  by  Data 
Translation  personnel. 

5.  ###ERR0R COULDN'T  6ET  ITEM  INTO  BUFFER,  name. 

Cause:  An  error  has  occurred  while  moving  data  from  the  source  database 
to  an  Internal  buffer.  This  Is  a fatal  error. 

Action:  Can  be  corrected  only  by  Data  Translation  personnel. 


& ###ERROR CR  ERROR#  n 

Cause:  An  ADBMS  error  has  occurred  While  creating  a record  In  the  SRIF. 

Action:  Same  as  #3. 

7.  ###ERROR DATABASE  NAME  NOT  FOUND,  nme  IGNORED. 

Cause:  The  database  name,  "name",  which  the  user  specified  as  a run-time 
parameter  could  not  be  found  In  the  SOU.  tables. 

Action:  Put  the  proper  database  name  In  the  "NAME**  parameter  In  the  run- 
time parameter  file  and  rerun  the  Reader.  The  correct  name  can 
be  found  In  IDS  Analyzer  ouptut.  Source  databases  which  have 
already  been  read  In  need  not  be  reprocessed. 

8.  ###ERR0R  IN  ADBMS  DDL  ANALYZER. 

Cause:  This  error  message  will  be  printed  after  other  errors  have  occurred. 

Action:  If  possible,  correct  all  errors  which  preceded  this  error.  Other- 
- wise,  this  can  be  fixed  only  by  Data  Translation  personnel. 

9.  ###ERR0R  IN  ADBMS  D6  INITIALIZATION. 

Cause:  See  #8. 

Action:  See  #8 

10.  ###ERR0R  IN  DDL  WRITER. 

Cause:  An  error  occurred  while  writing  the  ADBMS  DDL  for  the  SRIF. 

Action:  Correct  all  errors  which  preceded  this  message.  The  user  should 
be  sure  that  the  IDS  Analyzer  run  creating  the  Source  SODL 
tables  had  no  errors. 


11.  ##ERR0R PROBLEMS  IN  GETCRG. 

Cause:  The  Source  SDOL  tables  were  created  incorrectly. 

Action:  Recheck  IDS  Analyzer  output,  recreate  the  Source  SDDL  tables, 
and  then  run  the  Reader. 


12.  ###ERR0R RECORD  TYPE  n NOT  FOUND,  SKIPPED. 

Cause:  The  IDS  record  type  n Is  not  described  In  the  source  SDDL  tables 

Action:  Include  the  MO  section  for  record  type  n with  the  rest  of  the 
NO  section  and  run  the  IDS  Analyzer  to  create  the  source  SODL 
tables.  Then  run  the  Reader. 


13.  ###ERR0R  PROBLEMS  WITH  MVB  IN  "STRPOP 
###FATAL  ERROR,  RIF  HILL  BE  WRONG. 


Cause:  See  #5 


Action:  See  #5 


14.  ###ERR0R TRUNCATED  DOUBLE  WORD  INTEGER.  SET  TO  ZERO. 

OCTAL  OF  BUFFER  (1)  AND  BUFFER  (2). 

Cause:  An  error  has  occurred  while  converting  a double  word  Integer  to 

a single  word  Integer. 

Action:  This  problem  cannot  be  corrected.  Due  to  data  representation 

restrictions  In  ADBMS,  all  double  word  Integers  must  be  converted 
to  single  word  Integers.  If  truncation  occurs  In  the  conversion 
subroutine,  that  data  Item  Is  set  to  zero.  The  line  following 
this  error  message  will  have  the  octal  representation  of  the 
double  word  Integer  which  now  equals  zero. 


15.  ###FATAL  ERROR... AMS  ERROR#  n 


Cause:  See  #3 


Action:  See  #3 


16.  ###FATAL  ERROR... POPULATOR  NOT  OPENED. 

Cause:  The  DRT  was  not  properly  Initialized. 

Action:  This  error  message  should  be  preceded  by  other  errors  which  should 
be  corrected. 


17.  ###FATAL  ERROR... PROBLEMS  WITH  MVB  IN  MAIN. 
Cause:  See  #5. 

Action:  See  #5. 


Cause:  The  "NEXT"  pointer  field  for  the  master  record  of  set  namel  does 
not  exist. 


Action:  Note  that  this  message  will  be  printed  once  for  every  occurrence 
of  namel  and  name2.  If  the  set  namel  Is  not  a phantom  pointer 
relation,  the  61  levels  should  be  corrected  and  the  IDS  Analyzer 
should  be  rerun.  If  the  61  levels  are  correct  and  the  set  namel 
Is  not  a phantom  pointer  relation,  an  error  has  occurred  In  one 
of  the  sub-modules  and  It  can  be  fixed  only  by  Data  Translation 
personnel . 

19.  ***ERR  IN  GETITM—ARRAY  DIMENSION  OF  PITEM  & DITEM  IS  TOO  SMALL. 

Cause:  Too  many  match-key  Items  In  one  match-key  relation. 

Action:  Can  be  fixed  only  by  Data  Translation  personnel. 


20.  ***ERR  IN  6ETITM— STATEMENT#  n 

Cause:  This  error  message  Is  printed  only  after  other  errors  have  occurred. 

Action:  If  possible,  correct  all  other  errors  which  precede  this  message. 
Otherwise,  this  error  can  be  fixed  only  by  Data  Translation 
personnel . 

21.  ***ERR  IN  MKYREL-- ERROR  RETURN  FROM  GETITM. 

Cause:  See  #19. 

Action:  See  #19. 


i 


22.  ***ERR  IN  MKYREL— STATEMENT#n. 
Cause:  See  #20. 

Action:  See  #20. 


23.  ***ERR0R  IN  RT2SNN. 
Cause:  See  #5. 

Action:  See  #5. 


Note:  Errors  24  through  33  are  all  the  sane. 

24.  ...POPULATOR  - CHKSET  6ETS  AOBMS  ERROR#  n 

25.  ...POPULATOR  - CLSPOP  GETS  AOBMS  ERROR#  n 

26.  ...POPULATOR  - CPYSET  GETS  AOBMS  ERROR#  n 

27.  ...POPULATOR  - FANCHN  GETS  AOBMS  ERROR#  n 

28.  ...POPULATOR  - GETFST  GETS  AOBMS  ERROR#  n 

29.  ...POPULATOR  - GNEXT  GETS  AOBMS  ERROR#n 

30.  ...POPULATOR  - INSFST  GETS  AOBMS  ERROR#  n 

31.  ...POPULATOR  - INSNXT  GETS  AOBMS  ERROR#  n 

32.  ...POPULATOR  - POPIHT  GETS  AOBMS  ERROR#  n 

33.  ...POPULATOR  - UNION  GETS  AOBMS  ERROR#  n 


Cause:  See  #3 


Action:  See  #3 


34.  ...POPULATOR  COPYING  ERROR  Keyl  Key2. 

Cause:  The  Populator  was  unable  to  move  all  the  member  records  owned  by 

Keyl  to  Key2. 

Action:  Unless  this  error  was  preceded  by  some  other  errors.  It  can  be 
corrected  only  by  Data  Translation  personnel . 


35.  ...POPULATOR  - DETAIL  RECORD  POINTS  TO  ITSELF. 

Cause:  The  Populator  tried  to  link  a member  record  Into  a set.  The 
record's  "next"  field  was  equal  to  Its  reference  code. 

Action:  The  pointer  fields  are  Incorrect  In  the  source  IDS  database. 

They  must  be  corrected  before  the  Reader  will  run.  Data  Transla 
tlon  personnel  may  be  required  to  help  find  the  record  Instances 
In  the  IDS  database  which  have  the  problem. 

36.  ...POPULATOR  - ERROR  FROM  GFIRST. 

Cause:  This  error  message  will  be  preceded  by  other  errors. 

Action:  If  possible,  follow  the  suggested  action  for  all  errors  which 
preceded  this  message.  Otherwise,  this  error  can  be  corrected 
only  by  Data  Translation  personnel . 


! 


I 


37.  ...POPULATDR  - ERROR  FROM  INSFST. 

Cause:  See  #36.  } 4 

* r . ■ 

i 

Action:  See  #36. 

• ' . i 

38.  ...POPULATOR  - ERROR  FROM  UNION. 

Cause:  See  #36. 

Action:  See  #36. 

39.  ...POPULATOR  FOUND  THO  REAL  PARENTS  IN  IDS  08. 

Cause:  Two  records  were  found  to  be  the  owner  of  the  sane  set  Instance 
Action:  See  #35. 


40.  ...POPULATOR  - INSFST  INTERNAL  ERROR 
Cause:  See  #39. 

Action:  See  #35. 

41.  ...POPULATOR  - INSNXT  INTERNAL  ERROR. 

Cause:  See  #39. 

Action:  See  #35. 

42.  ...POPULATOR  - INTERNAL  ERROR  IN  DRT. 

Cause:  A relation  Is  Missing  the  DRT  or  a sibling  name  has  been 
omitted. 

Action:  This  error  can  be  corrected  only  by  Data  Translation  personnel 

43.  ...RECORD  TYPE  IS  NEITHER  MASTER  NOR  OETAIL. 

Cause:  The  Populator  nodule  was  passed  bad  data. 

Action:  This  error  can  be  corrected  only  by  Data  Translation  personnel 


I 


44.  ...POPULATOR  - RECORDS  ACCESSED  OUT  OF  SEQUENCE. 

Cause:  A record  was  retrieved  whose  reference  code  was  less  than  or 
equal  to  the  preceding  record's  reference  code. 

Action:  There  are  several  reasons  why  the  reference  codes  are  not  In 

ascending  order.  That  situation  Is  left  to  the  user  to  correct, 
after  which  the  entire  Reader  should  be  rerun. 


45.  ...POPULATOR  - ROUTINE  POPLAT  ADBMS  ERROR#  n. 
Cause:  See  #3. 

Action:  See  #3. 


46.  ...POPULATOR  - TABLES  NOT  INITIALIZED. 

Cause:  The  DRT  was  not  successfully  Initialized. 

Action:  Unless  this  message  was  preceded  by  other  errors  which  can  be 
corrected,  this  error  can  be  corrected  only  by  Data  Translation 
personnel . 


47.  ...POPULATOR  - TROUBLE  INITIALIZING  DRT. 

Cause:  This  error  message  will  probably  be  preceded  by  other  error 
messages. 

Action:  Follow  the  action  detailed  for  the  other  errors.  If  there  were 
no  preceding  error  messages,  be  sure  the  SDDL  tables  were  created 
correctly. 


48.  ...POPULATOR  - UNION  HAS  INTERNAL  ERROR  IN  DRT. 

Cause:  This  error  message  will  be  preceded  by  other  error  messages. 

Action:  See  #3  and  #35. 
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APPENDIX  D 

RESTRUCTURE!!  ERROR  MESSAGES 


This  appendix  contains  a list  of  all  Restructurer  error  messages 
alphabetized  by 

1)  numeric  characters 

2)  alphabetic  characters 

3)  special  characters 

Restructurer  errors  are  of  two  types.  Non-fa tal  errors  allow  the 
Restructurer  to  continue  executing  In  order  to  detect  as  many  problems 
as  possible  In  one  run.  Fatal  errors  terminate  the  run  Immediately, 
since  they  are  usually  of  a nature  that  makes  further  execution  pointless 
(e.g.,  unable  to  open  a database).  Some  error  conditions  are  recoverable; 
for  example.  If  the  Restructurer  buffer  space  Is  not  sufficient  to  access 
a group  of  compatible  access  paths  all  at  once.  It  will  attempt  to  access 
as  many  together  as  It  has  room  for  and  will  access  the  rest  separately. 

An  error  which  the  Restructurer  Is  unable  to  recover  from  causes  the 
cancellation  of  Activity  03,  the  SUTILITY  copy  of  the  Target  RIF  database 
back  to  the  permanent  file.  In  the  error-explanations  that  follow, 
assume  this  Is  the  case  unless  It  Is  mentioned  specifically  that  the 
results  of  the  run  will  still  be  consistent. 


In  the  explanations  that  follow,  "Cause"  describes  the  probable 
cause  of  the  error  condition.  "Action"  describes  the  action  taken 
by  the  Restructurer  If  the  particular  error  condition  occurs. 


1.  ERROR  IN  COMPAR.  IPOS* 


, I ERR* 


Cause:  An  error  has  occurred  while  performing  qualification  on  a source 
record  Instance. 

Action:  More  error  messages  will  follow. 


rl 
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2.  ERROR  IN  CONSTR.  IrOS* 


, I ERR- 


Cause:  An  error  has  occurred  while  attempting  to  build  a target  record 
Instance. 

Action:  More  error  messages  will  follow. 


3.  ERROR  IN  CONVRT.  IPOS- 


, I ERR* 


Cause:  An  error  has  occurred  while  Item  conversion  (e.g.,  Integer-to- 
character  type)  was  being  performed  prior  to  assigning  data  to 
a target  Item. 

Action:  More  error  messages  will  follow. 


LU 


4.  ERROR  IN  INTQL1 . IPOS* , I ERR* 

Cause:  An  error  has  occurred  while  performing  an  Inter-Item  qualiflca 
tlon. 


Action:  More  error  messages  will  follow 


5.  ERROR  IN  INTQL2.  IPOS* , I ERR* 

Cause:  An  error  has  occurred  while  performing  an  Inter-Item  qualifi 

cation. 


More  error  messages  will  follow 


Action 


6.  ERROR  IN  QUAL.  IPOS* , IERR* 

Cause:  An  error  has  occurred  while  performing  qualification  on  a source 

record  Instance. 


Action:  More  messages  will  follow 


7.  ERROR  IN  SITMMV.  IPOS’ 


Cause:  An  error  has  occurred  while  assigning  source  item  values  to  their 

corresponding  target  Items. 

Action:  More  messages  will  follow. 


7.5  STATISTICS  INCOMPLETE  DUE  TO  LACK  OF  STORAGE 


Because  of  a lack  of  storage  for  statistics,  the  Restructurer  was 
unable  to  compile  statistics  for  the  entire  run.  While  the 
statistical  summary  will  be  Incomplete,  this  in  no  way  affects 
the  success  or  failure  of  the  run. 


Cause 


Action:  Normal  execution  of  the  wrapup  procedure  continues 


######END-OF-FILE  DETECTED  ON  USER  INPUT-#END-USER-INPUT  CARD 
SIMULATED###### 


Cause:  #END-USER- INPUT  Directive  was  not  used 

and  not  an  error. 


This  Is  merely  a warning 


End  of  User-Input  Directives  Is  assumed 


Action 


ABORT****** 


Cause:  An  error  has  occurred  during  the  Restructurer  run  that  caused  the 
operating  system  to  terminate  It  (e.g. , processor  time  exceeded), 
or  job  aborted  by  user.  Results  of  the  run  will  be  Inconsistent. 

Action:  The  Restructurer  abort  procedure  Is  executed  and  a statistical 
summary  Is  printed.  Activity  03  is  cancelled. 


D-3 


10.  ******ADBMS  ERROR  IN  UINPUT;  RETURN  CODE*  ****** 

Cause:  An  ADBMS  error  occurred  while  processing  the  User- Input 
Directives.  Consult  Data  Translation  Project  personnel. 

Action:  More  error  messages  will  follow. 

11.  ******  DATABASE  INITIALIZER  ERROR  IN  UINPUT;  RETURN  CODE*  ***** 

Cause:  ADBMS  Database  Initializer  was  unable  to  Initialize  the  target 
RIF  database.  Consult  Data  Translation  Project  personnel . 

Action:  More  error  messages  will  follow. 


12.  ******dol  ANALYZER  ERROR  IN  UINPUT;  RETURN  CODE- 

Cause:  DDL  output  by  ADBMS  DDL  Writer  Is  Inconsistent. 

Translation  Project  personnel. 

Action:  More  error  messages  will  follow. 


Consult  Data 


13.  ******DDL  WRITER  ERROR  IN  UINPUT;  RETURN  CODE-  ****** 

Cause:  Either  (1)  Inconsistencies  in  target  SDDL  tables,  or  (2)  Internal 

logic  error  In  ADBMS  DDL-Wrlter.  If  (1)  can  be  ruled  out, 
consult  Data  Translation  Project  personnel. 

Action:  More  error  messages  will  follow. 

14.  ******ERR0R  IN  MAIN  CONTROL-ABNORMAL  RETURN  CODE* FROM 

STKBLD****** 

Cause:  The  Restructurer  Main  Control  has  received  an  uninterpretable 

return  code  from  the  Stack  Builder  subroutine.  Core  may  have 
been  accidentally  written.  Results  of  the  run  may  be  Inconsis- 
tent. Consult  Data  Translation  Project  personnel. 

Action:  The  normal  wrapup  procedure  Is  executed  and  a statistical 
summary  Is  printed.  Activity  03  Is  cancelled. 

15.  ******ERR0R  IN  MAIN  CONTROL— DINT  UNSUCCESSFUL;  RETURN  CODE*  *** 

Cause:  The  Restructurer  Main  Control  was  unable  to  Initialize  the  data- 
base management  system,  ADBMS.  This  Indicates  a serious  problem 
In  the  ADBMS  routines  In  the  Translator  Library;  e.g..  It  may 
not  have  been  restored  correctly  from  the  systen  tape.  If  this 

Is  not  the  case,  consult  Data  Translation  Project  personnel. 

* 

Action:  The  Restructurer  run  Is  cancelled,  along  with  Activity  03.  No 
further  execution  takes  place. 


16.  *****ERROR  IN  MAIN  CONTROL-NAME  TO  POINTER  CONVERSION  ERROR;  RETURN 


Cause:  An  error  occurred  while  converting  ADBMS  names  In  the  TDL  Tables 
to  their  symbolic  pointers;  see  previous  messages  on  Restructurer 
Report. 

Action:  The  Restructurer  run  Is  cancelled,  along  with  Activity  03.  No 
further  execution  takes  place. 


17.  ******ERR0R  IN  MAIN  CONTROL-UNABLE  TO  CLOSE  ALL  DATABASES;  RETURN 
CODE-  ****** 


The  Restructurer  Main  Control  was  unable  to  close  all  databases 
previously  opened.  May  be  caused  by  unsuccessful  earlier  attempt 
to  open  a physically  Inconsistent  database.  Any  results  from  the 
run  are  probably  Inconsistent. 


Cause 


Action:  Activity  03  Is  cancelled  to  preserve  the  previous  contents  of 
the  Target  RIF  database. 


18.  ******ERR0R  IN  MAIN  CONTROL-UNABLE  TO  OPEN  NAMES  TDL  TABLES;  RETURN 
COPE-  ****** 

Cause:  The  Restructurer  Main  Control  was  unable  to  open  the  "Names11  copy 
of  the  TDL  Tables.  The  permanent  copy  of  the  TDL  Tables  Is 
probably  physically  Inconsistent  and  should  be  re-generated. 

Action:  The  Restructurer  run  Is  cancelled,  along  with  Activity  03.  No 
further  execution  takes  place. 


19.  ******ERR0R  IN  MAIN  CONTROL-UNABLE  TO  OPEN  POINTERS  TDL  TABLES 
RETURN  COPE-  ****** 


here  to  the  "Pointers 


Cause: 


copy  of  the  TDL  Tables 
Action:  Same  as  error  #18. 


20.  ******£ RROR  IN  MAIN  CONTROL-UNABLE  TO  OPEN  SRIF;  RETURN  CODE- 

Cause:  The  Restructurer  Main  Control  was  unable  to  open  the  Source  RIF 
database.  It  Is  probably  physically  Inconsistent  and  should  be 
re-generated. 

Action:  The  Restructurer  run  is  cancelled,  along  with  Activity  03.  No 
further  execution  takes  place. 


Cause:  An  error  occurred  while  processing  the  User-Input  Directives;  see 
previous  messages  on  Restructurer  Report. 

Action:  The  Restructurer  run  Is  cancelled,  along  with  Activity  03.  No 
further  execution  takes  place. 


23.  ******ERR0R  IN  NTOPTR--BAD  (A)  IN  TDL  TABLES;  SGNAME/SSETNH* 

(B)  / (C)  ****** 

Cause:  An  Inconsistent  ADBMS  name  from  the  Source  RIF  database  has  been 
found  in  the  TDL  Tables  while  attempting  to  convert  It  to  Its 
symbolic  pointer.  If  (A)  Is  "SGNAME",  the  bad  name  was  a source 
record  type  name;  If  (A)  Is  “SSETNM",  the  bad  name  was  a source 
set  type  name.  The  (B)/(C)  combination  gives  the  source  record 
name  (B)  and  the  source  set  name  (C)  that  caused  the  error.  The 
most  likely  cause  of  this  error  Is  failure  to  re-generate  one  or 
both  of  the  TDL  Tables  and  Source  RIF  database  after  the  SDDL 
Tables  have  been  re-generated  with  changes.  Both  the  TDL  Tables 
and  the  Source  RIF  database  should  be  re-generated  before  attempting 
to  re-run  the  Restructurer. 

Action:  Same  as  error  #24. 


24.  ******ERR0R  IN  NTOPTR— BAD  (A)  IN  THE  TDL  TABLES;  TGNAHE/SYSSET- 
(B)  / 1C)  ****** 

Cause:  An  Inconsistent  ADBMS  name  from  the  Target  RIF  database  has  been 
found  In  the  TDL  Tables  while  attempting  to  convert  It  to  Its 
symbolic  pointer.  If  (A)  Is  "tGNAME8 • the  bad  name  was  a target 
record  type  name;  if  (A)  Is  "SYSSET",  the  bad  name  was  a target 
system  set  type  name.  The  (B)/(C)  combination  gives  the  target 
record  name  (B)  and  associated  system  set  name  (C)  that  caused 
the  error.  The  most  likely  cause  of  this  error  Is  failure  to 
re-generate  the  TDL  Tables  after  the  SDDL  Tables  have  been  re- 
generated with  changes.  TDL  Tables  should  be  re-generated  before 
attempting  to  run  the  Restructurer  again. 


i 


Action:  Name  to  pointer  conversion  continues  In  order  to  detect  all  errors 
In  one  run.  This  messages  will  be  followed  by  errors  #27  and  #16. 
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25.  ******ERRQR  IN  NTOPTR— BAD  SINAME  IN  TOL  TABLES*  (A)  ; SGNAME/SSETNM* 

(B)  / (C)  ****** 

Cause:  An  Inconsistent  ADBMS  name  fro*  the  Source  RIF  database  has  been 
found  In  the  TOL  Tables  while  attempting  to  convert  It  to  Its 
symbolic  pointer.  In  this  case.  It  Is  a bad  source  Item  name, 
given  by  (A).  The  (B)/(C)  combination  gives  the  source  record 
type  (B)  of  which  It  Is  an  Item,  and  the  source  set  name  (C) 
associated  with  the  source  record  name  by  virtue  of  being  a set 
along  which  (B)  Is  accessed  In  a particular  access  path.  See 
error  #23  for  likely  cause. 

Action:  Same  as  error  #24. 


26.  ***+**ERR0R  IN  NTOPTR— BAD  TINAHE  IN  TOL  TABLES*  (A)  ; TGNAME- 

(g) 

Cause:  An  Inconsistent  ADBMS  name  from  the  Target  RIF  database  has  been 
found  In  the  TOL  Tables  while  attempting  to  convert  It  to  Its 
symbolic  pointer.  In  this  case.  It  Is  a bad  target  Item  name, 
given  by  (A);  (B)  gives  the  target  record  type  of  which  (A)  Is 
an  Item.  See  error  #24  for  likely  cause. 

Action:  Same  as  error  #24. 


27.  ******£RRQR  IN  NTOPTR— THE  ABOVE  ADBMS  NAMES  FROM  THE  TDL  TABLES  ARE 
INCONSISTENT****** 

Cause:  Inconsistent  ADBMS  name(s)  from  the  TDL  Tables  have  been  found 

In  the  TDL  Tables  while  attempting  to  convert  them  to  their 
symbolic  pointers.  See  previous  messages  on  Res tructurer  Report. 

Action:  Name  to  pointer  conversion  Is  done.  This  message  will  be  followed 
by  error  #16. 


28.  ******ERR0R  IN  RSTABT— UNABLE  TO  CLOSE  ALL  DATABASES;  RETURN  COOE- 


Cause:  The  Restructurer  abort  routine  was  unable  to  close  ell  open  data- 

bases following  an  error  that  produced  error  #9.  Results  of  the 
run  will  be  Inconsistent. 

Action:  The  run  Is  terminated  by  the  operating  system. 


^ M 
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29.  ******ERROR  IN  SRCACC-10  NON-FATAL  ERRORS  HAVE  OCCURRED****** 

Cause:  10  non-fatal  errors  have  occurred  while  accessing  the  current 
stack  (set  of  access  paths). 

Action:  Same  as  error  #33. 


30.  ******ERR0R  IN  SRCACC-CANNOT  6ET  FIRST  INSTANCE  AT  LEVEL  ; 

RETURN  CODE*  ****** 

Cause:  The  Restructurer  was  unahle  to  retrieve  the  first  source  record 
Instance  on  some  source  set.  Source  RIF  database  Is  probably 
Inconsistent. 

Action:  The  condition  Is  treated  as  If  there  were  no  records  on  the  particular 
source  set,  and  the  Restructurer  attempts  to  continue  accessing 
the  current  stack  (set  of  access  paths). 


31.  ******ERR0R  IN  SRCACC-CANNOT  GET  NEXT  INSTANCE  AT  LEVEL; ; RETURN 

CODE*  ****** 

Cause:  The  Restructurer  was  unable  to  retrieve  the  next  source  record 
Instance  on  some  source  set.  Source  RIF  database  Is  probably 
Inconsistent. 

Action:  The  condition  Is  treated  as  If  there  were  no  more  records  on  the 
particular  set,  and  the  Restructurer  attempts  to  continue 
accessing  the  current  stack  (set  of  access  paths). 


32.  ******ERR0R  IN  SRCACC-CONSTRUCTOR  ERROR  AT  LEVEL 


; RETURN  CODE- 


Cause:  An  error  has  occurred  while  attempting  to  construct  a target 
record  Instance. 

Action:  The  Restructurer  attempts  to  continue  accessing  the  current  stack 
(set  of  access  piths). 


33.  ******ERR0R  IN  SRCACC— MULTIPLE  DATABASE  ERROR  » ****** 

Cause:  An  error  occurred  while  manipulating  A06MS  database  currency  during 
the  accessing  of  an  access  path. 

Action:  Accessing  of  the  current  stack  (access  paths)  Is  terminated. 
Restructuring  continues  with  the  next  set  of  access  path(s). 

This  message  will  be  followed  by  error  #36. 


34.  ******ERROR  IN  SRCACC— NO  APPTRS  AT  SOURCE  STACK  LEVEL  ****** 

Cause:  A Rastructurer  Internal  logic  error  has  occurred.  Consult  Data 
Translation  Project  personnel. 


Action:  Same  as  error  #33. 


35.  ******ERRQR  IN  SRCACC— QUALIFIER  ERROR  AT  LEVEL, 


; RETURN  CODE* 


Cause:  An  error  has  occurred  while  attesting  to  perfona  qualification 
on  a source  record  Instance. 

Action:  The  condition  Is  treated  as  If  the  record  had  failed  qualifica- 
tion, and  the  Rastructurer  attempts  to  continue  accessing  the 

current  stack  (set  of  access  paths). 

> 

36.  ******ERR0R  IN  SRCACC- SOURCE  ACCESSOR  ABORTED****** 

Cause:  Either  10  non-fatal  errors  or  1 fatal  error  have  occurred  while 
accessing  the  current  stack  (set  of  access  paths). 

Action:  Processing  of  the  current  stack  temlnates.  Nora  error  messages 
will  follow. 


37.  ******ERR0R  IN  SRCACC— UNABLE  TO  MOVE  SRIF  SYSTEM  RECORD  TO  WORK  AREA; 
RETURN  CODE*  ****** 

Cause:  Inconsistency  exists  In  the  Source  RIF  database.  Consult  Data 
Translation  Project  personnel . 


Action: 


as  error  #33. 


38.  ******ERR0R  IN  STAKAP— ADBMS  ERROR  # ****** 

Cause:  An  AOBNS  error  has  occurred  while  attempting  to  stack  a particular 
access  path. 

Action:  More  error  messages  will  follow. 


38.  ******ERR0R  IN  STAKAP- IMPOSSIBLE  RETURN  COOE  FROM  STAKNO*  ****** 

Cause:  An  uninterpretable  error  return  code  has  been  returned  by  a lower 
level  subroutine  while  attempting  to  stack  a particular  access 
path.  Core  may  have  been  accidentally  overwritten. 

Action:  More  error  massages  will  follow. 


ID 
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40.  ******ERR0R  III  STAKAP—UNABLE  TO  STACK  ACCESS  PATH;  APPTR  STORAGE 
EXHAUSTED***** 

Caust:  The  Restructurer  ms  unable  to  put  a particular  access  path  on 
the  stack  due  to  lack  of  Inttmal  buffer  space. 

Action:  More  error  Messages  will  follow. 

41.  ******ERR0R  IN  STAKAP-- UNABLE  TO  STACK  ACCESS  PATH;  ROOT  KEY- 

Cause:  An  error  has  occurred  while  attenptlng  to  stack  a particular 
access  path. 

Action:  More  error  Messages  will  follow. 

42.  ******ERR0R  IN  STAKAP-UNABLE  TO  UNSTACK  PARTIAL  ACCESS  PATH****** 

Cause:  An  error  has  occurred  In  an  error  recovery  procedure  which  ms 
attempting  to  salvage  the  logically  consistent  part  of  a stack 
(set  of  access  paths). 

Action:  More  error  Messages  will  follow. 


43.  ******ERR0R  IN  STAKND-- A08MS  ERROR  #. 


. SWITCH* 


Cause:  An  ADBMS  error  has  occurred  while  attempting  to  put  a source 
record  type  from  an  access  path  on  the  stack. 

Action:  More  error  messages  will  follow. 


44.  ******ERR0R  IN  STAKND-- APPTR  STORAGE  EXHAUSTED****** 


Cause: 


as  error  #47. 


Action:  More  error  messages  will  follow. 


45.  ****** ERROR  IN  STAKNO— BAD  APPTR  INDEX  RETRIEVED  FROM  NODE  REC0RD_ 
INDEX-  ****** 

Cause:  Same  as  error  #49. 

Action:  More  error  messages  will  follow. 


******ERROR  IN  STAKNO — NODE  RECORD  NOT  A MEMBER  OF  AN  INSTANCE  OF 
EITHER  OM  OR  NO;  SWITCH*  ****** 


Action:  More  error  Messages  will  follow 


47>  *******ERROR  IN  STAKND— SRCSTK  STORAGE  EXHAUSTED****** 

Cause:  The  Restructurer  mss  unable  to  put  a source  record  type  froM  an 
access  path  on  the  stack  due  to  lack  of  Internal  buffer  space. 

Action:  More  error  Messages  will  follow. 


48.  ******ERR0R  IN  STAKND— UNABLE  TO  STACK  NODE*  ****** 

Cause:  An  error  has  occurred  while  attempting  to  put  a source  record 
type  froM  an  access  path  on  the  stack. 

Action:  More  error  Messages  will  follow. 


49.  ******error  IN  STAKND— TDL  DDL  INDICATES  NODE  RECORD  NOT  LEGAL  MEMBER 
OF  OM  AND/OR  MO;  SWITCH*  ****** 

Cause:  Inconsistency  exists  In  the  TDL  Tables.  Consult  Data  Translation 
Project  personnel. 

Action:  More  error  messages  will  follow. 


50.  ******errqr  in  STAPRT--ADBMS  ERROR  # 


Cause:  An  A08MS  error  has  occurred  during  the  wrapup  procedure.  Results 
of  the  run  may  be  Inconsistent. 


Action:  Wrapup  procedure  Is  terminated  at  the  point  of  the  error 


51.  ****+*ERROR  IN  STAPRT— MULTIPLE  DATABASE  ERROR  # 


Cause:  An  error  has  occurred  while  Manipulating  AD6MS  database  currency 
during  the  wrapup  procedure.  Results  of  the  run  May  be  Incon- 
sistent. 

Action:  Wrapup  procedure  Is  tennlnated  at  the  point  of  the  error. 


52.  ******£RROI  IN  STKBLD— AD0MS  ERROR  i ****** 

Cause:  An  AD6MS  error  has  occurred  during  the  stacking  of  access  path. 

Action:  The  current  access  peth  Is  discarded  and  restructuring  continues 
with  the  next  access  path. 


53.  ******error  in  stkbld— impossible  return  code  from  _»  _****** 

Cause:  A lower  level  routine  has  returned  an  uninterpretable  error  return 
code  while  preparing  a stack.  Core  may  have  been  accidentally 
overwritten. 

Action:  Same  as  error  #55. 


54.  ******ERR0R  IN  STKBLD— INCOMPLETE  BUT  USABLE  STACK;  RETURN  CODE' 


Cause:  An  Incomplete  but  logically  consistent  stack  has  been  prepared. 

Results  of  the  run  may  be  Inconsistent.  Study  Statistical  Summary 
carefully,  along  with  any  other  error  messages  on  the  report. 
Consult  Data  Translation  project  personnel  If  necessary. 

Action:  Restructuring  continues  with  the  current  stack. 


55.  ******ERR0R  IN  STKBLD— MULTIPLE  DATABASE  ERROR  # ****** 

Cause:  An  error  has  occurred  while  manipulating  ADBMS  database  currency 
during  the  stacking  of  an  access  path. 

Action:  Restructuring  stops  at  the  point  of  the  error. 


56.  ******ERROR  IN  STKBLD— STACK  ABORTED****** 


Errors  have  occurred  rendering  the  current  stack  useless 


Cause 


Action:  The  stack  Is  discarded.  Restructuring  continues  with  the  next 
access  path. 


57 .  ******ERR0R  IN  STKBLD— STACK  BUILDER  ABORTED****** 

Cause:  Serious  errors  have  occurred  that  warrant  termination  of  the 

Restructurer  run. 

Action:  The  run  Is  prematurely  terminated. 


NOT  ACCESSED  SUCCESSFULLY 


58.  ******ERR0ft  IN  STKBLD-- STACK  NO 
RETURN  COPE*  ****** 


Cause:  The  Indicated  stack  ees  not  processed  successfully.  Results  from 
the  corresponding  access  paths  are  probably  Inconsistent. 

Action:  Restructuring  continues  with  the  next  access  path. 


59.  ******ERR0R  IN  STKBLO-- UNABLE  TO  ALLOCATE  WORK  AREA  STORAGE;  RETURN 
COPE*  ****** 


Cause:  The  Restructurer  ms  unable  to  allocate  work  area  storage  for 
the  current  stack. 


Action:  Sane  as  error  #52 


60.  ******ERR0R  IN  STKBLD-- UNABLE  TO  DUMP  STACK  NO 


Cause:  Restructurer  internal  loclc  error.  Consult  Data  Translation 
Project  personnel. 

Action:  Sane  as  error  #55. 


61.  *****ERR0R  IN  STKBLD— UNABLE  TO  INITIALIZE  WORK  AREA;  RETURN  CODE' 


Cause:  The  Restructurer  ms  unable  to  Initialize  the  ADBMS  work  area 
Consult  Data  Translation  Project  personnel . 

Action:  Restructuring  stops  at  the  point  of  the  error. 


62.  ******ERR0R  IN  STKBLD-- UNABLE  TO  STACK  FIRST  ACCESS  PATH;  RETURN 
COPE*  ****** 


The  Restructurer  ms  unable  to  put  the  first  access  path  selected 


Action:  Restructuring  stops  at  the  point  of  the  error 


Action:  Sane  as  error  #52 
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64.  ******ERR0R  1#  STKCMP— IMPOSSIBLE  RETURN  CODE  FROM  STAMP-, 
Cause:  Sue  as  error  #53. 

Action:  Same  as  error  #53. 


65. 


►ERROR  IN  STKCMP--STACK  HAS  LOST  ITS  INTE6RITY;  FIRST  ROOT* 


Cause:  Errors  have  occurred  rendering  the  current  stack  useless. 
Action:  Same  as  error  #52. 

66.  ****** error  in  STKCMP— UNABLE  TO  STACK  ALL  COMPATIBLE  ACCESS  PATHS 
FOR  FIRST  ROOT- ; STACK  STILL  USABLE****** 

Cause:  Errors  have  occurred  preventing  the  stacking  (together)  of  a 

group  of  compatible  access  paths. 

Action:  Restructuring  continues  with  a partial  stack. 
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57.  ******£rror  in  STKDMP-- BAD  APPTR  INDEX  DETECTED  IN  SOURCE  STACK,- 


Cause:  Same  as  error  #60. 
Action:  Same  as  error  #60. 


68. 


►ERROR  IN  STKDMP— BAD  STKBTM  PASSED-, 


* — *- 
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Cause:  Same  as  error  #60. 
Action:  Same  as  error  #60. 


69. 


►ERROR  IN  STKPRP— ADBMS  ERROR  #, 


Cause:  Same  as  error  #52. 

Action.  Same  as  error  #52. 

70.  ****** ERROR  IN  STKPRP— MULTIPLE  DATABASE  ERROR  #, 
Cause:  Same  as  error  #55. 

Action:  Same  as  error  #55. 


Cause:  Initialized  work  area  space  Is  Insufficient  for  the  current  stack 

Action:  Error  recovery  Is  Initiated.  See  error  #66. 


72.  ******ERR0R  IN  UINPUT— ACTIVE-TDLAPS  CARO  ALREADY  ENCOUNTERED; 

CARO  WAS— 

Cause:  User  Input  Processor  has  read  a second  lACTIVE-TDLAPS  directive; 
only  one  Is  allowed. 

Action:  The  bad  card  Is  printed  following  the  message.  Processing  continues 
to  find  more  errors*  If  any. 


73.  ******£RR0R  IN  UINPUT— EXECUTION-HOHITOR  CARD  ALREADY  ENCOUNTERED 
CARD  WAS-- 

Cause:  User  Input  Processor  has  read  a second  #EXECUT ION -MONITOR* 

directive;  only  one  Is  allowed. 

Action:  Same  as  error  #72. 


******ERR0R  IN  UINPUT- EXPECTING  HASH  INFO  AFTER  USER-HASH- INPUT  CARD 
CARO  WAS— 

>:  #USER-HASH- INPUT  directive  was  not  followed  by  any  hash  input 

statements. 


Cause 


Action:  Same  as  error  #72 


75.  ******ERR0R  IN  UINPUT— EXPECTING  HASH  INFO  AFTER  USER -HASH -INPUT 

CARD;  GOT  EOF****** 

Cause:  #USER-HASH- INPUT  directive  was  last  line  of  User-Input  Directives 

It  must  be  followed  by  at  least  one  hash  Input  statement. 

Action:  End  of  User-Input  Directives  Is  assumed. 


76.  *+****ERR0R  IN  UINPUT-EXPECTIN6  RESTRUCTURER  CONTROL  CARD;  CARD  WAS 

Cause:  User-Input  Processor  was  expecting  a User- Input  Directive*  but 

the  Input  line  read  was  not  a legal  directive.  Most  probable 
cause  Is  a TDLAP  name  following  the  ALL-TOLAPS-ACTIVE  keyword. 

Action:  Same  as  error  #72. 
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77.  »*«***EWW  IN  UINPUT— EXPECTING  TDLAP  NAME  AFTER  ACTIVE-TDLAPS 
CARO;  CARO  MAS— 

Cause:  A User-Input  Directive  Immediately  followed  the  #ACTIVE-TDLAPS 
directive.  At  least  one  TDLAP  name  or  ALL-TDLAPS-ACTIVE  must 
follow  lACTIVE-TOLAPS. 

Action:  Same  as  error  #72. 


78.  ******ERROR  IN  UINPUT—  EXPECTING  TOLAP  NAME  AFTER  ACTIVE-TDLAPS 
CARO;  GOT  EOF****** 

Cause:  lACTIVE-TOLAPS  directive  was  last  line  of  User-Input  Directives. 

It  must  be  followed  by  at  least  one  TOLAP  name  or  ALL-TDLAPS- 
ACTIVE. 

Action:  Same  as  error  #75. 


79a  ******erroR  IN  UINPUT- ILLEGAL  OPTION  ON  EXECUTION-MONITOR  CARD; 
CARD  MAS— 

Cause:  EXECUTION-MONITOR-dl recti ve  not  followed  by  either  ON  or  OFF 

with  no  Intervening  blanks.  These  are  the  only  two  options 
available. 

Action:  Same  as  error  #72. 


80.  ******£1111011  iN  UINPUT— ILLEGAL  OPTION  ON  RUN  CARD;  CARD  WAS— 

Cause:  #RUN*d1rect1ve  not  followed  by  either  INITIALIZE  or  CONTINUE 
with  no  Intervening  blanks.  These  are  the  only  two  options 
available. 

Action:  Same  as  error  #72. 


81.  ******£RR0R  IN  UINPUT— ILLEGAL  RESTRUCTURER  CONTROL  CARO;  CARD  WAS— 

Cause:  The  Input  line  read  was  not  a legal  User-Input  Directive. 
Probably  misspelled  or  contatns  Imbedded  blanks. 

Action:  Same  as  error  #72. 


82.  ******ERR0R  IN  UINPUT-RUN  CARD  HAS  ALREADY  BEEN  ENCOUNTERED; 

CARO  MAS- 

Cause:  User-Input  Processor  has  read  a second  #RUN«d1 recti ve;  only  one 
Is  allowed. 


Action:  Same  as  error  #72. 
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83.  ******ERROR  IN  UINPUT--TDLAP  NAME  (A)  NOT  FOUND  ON  ROOTS  SET****** 

Cause:  The  user  has  requested  TDLAP  (A)  to  ta  active;  however,  no  such 
TOLAP  name  exists  In  the  TDL  tables.  Check  TDL  description  for 
correct  spelling. 

Action:  Processing  continues  to  find  more  errors.  If  any. 

84.  *****+ERR0R  IN  UINPUT--USER-HASH- INPUT  CARD  ALREADY  ENCOUNTERED; 

CARO  WAS— 

Cause:  User-Input  Processor  has  read  a second  IUSER-HASH-INPUT  directive; 
only  one  Is  allowed. 

Action:  Same  as  error  #72. 
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85.  ******ERR0R  RECOVERY  FAILED****** 

Cause:  The  error  condition  associated  with  errors  #71  and  #86  could  not 
be  recovered  from.  This  may  result  from  too  many  access  paths 
being  compatible.  Restructuring-by-parts  should  .be  used;  l.e., 
only  a few  active  access  paths  per  run. 

Action:  More  error  messages  will  follow. 


86.  ******ERR0R  RECOVERY  INITIATED;  WORK  AREA  RE-INITIALIZED  WITH 

PAGES****** 

Cause:  Lack  of  Initialized  work  area  space. 

Action:  More  work  area  space  is  Initialized.  Either  error  #87  or  #85 
should  follow  this  message. 


87.  ******ERR0R  RECOVERY  SUCCESSFUL****** 


Cause:  The  error  condition  associated  with  errors  #71  and  #86  has  been 
successfully  recovered  from. 


Action:  Restructuring  continues.  Results  of  the  run  will  be  good  as  far 

as  this  error  condition  Is  concerned;  l.e..  Activity  03  will  not  be 
cancelled. 


...  < 


88.  ******ERROR(S)  IN  PHASE  II  -ABNORMAL  TERMINATION****** 

Cause:  Fatal  error(s)  during  Phase  II  of  the  Restructuring  run  caused 

premature  termination  of  execution.  Results  of  the  run  are 
probably  Inconsistent. 

Action:  The  normal  wrapup  procedure  Is  executed  and  a Statistical  Summary 
Is  printed.  Activity  03  Is  cancelled. 


89.  ******ERR0R(S)  IN  PHASE  II,  BUT  ABLE  TO  TERMINATE  NORMALLY****** 

Cause:  Non-fatal  error (s)  occurred  during  Phase  II  of  the  Restructurer 

run,  but  none  serious  enough  to  warrant  premature  termination  of 
the  run.  Results  of  the  run  are  probably  Inconsistent. 

Action:  The  normal  wrapup  procedure  is  executed  and  a Statistical  Summary 
Is  printed.  Activity  03  is  cancelled. 


Q 


y 
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90.  ******EXECUTION  DISASTER  IN  NAME  TO  POINTER  CONVERSION  LINE#* 
I ERR- 


Cause: 


An  error  has  occurred  in  an  ADBMS  subroutine  while  converting 
ADBMS  names  In  the  TDL  Tables  to  their  symbolic  pointers.  TDL 
Tables  may  be  physically  Inconsistent  and  should  be  re-generated. 
If  this  Is  not  the  case,  consult  Data  Translation  Project 
personnel . 


Action:  Name  to  pointer  conversion  terminates  Immediately.  This  message 
will  be  followed  by  error  #16. 


91.  ******MULTIPLE  DATABASE  ERROR  IN  UINPUT;  RETURN  CODE* 


Cause:  An  error  occurred  while  manipulating  ADBMS  database  currency 
during  processing  of  the  User-Input  Directives.  Consult  Data 
Translation  Project  personnel. 


Action:  Processing  of  the  User-Input  Directives  terminates  Immediately. 
More  error  messages  will  follow. 


92.  ******RESTRUCTURER  ABORT  PROCEDURE  DONE****** 
Cause: 


This  message  Indicates  that  the  Restructurer  abort  procedure 
finished  (see  error  #9). 


Action:  The  run  Is  terminated  by  the  operating  system. 


93.  ******RESTRUCTURER  RUN  CANCELLED****** 

Cause:  A fatal  error  has  occurred  In  Phase  I of  the  Restructurer 
see  previous  Messages  on  Restructurer  Report. 

Action:  Self-explanatory;  no  restructuring  will  be  performed. 


*•  *«~^ING--TRANS-NAME  CARD  ALREADY  ENCOUNTERED;  F0U0NIN6  CARD 
IGNORED— 

Cause:  User-Input  Processor  has  read  a second  #TRANSLATION-N0E-d1 recti ve 
only  the  first  one  Is  accepted.  This  Is  not  an  error,  only  a 
warning.  J 

Action:  Sane  as  error  #72. 


WRITER  ERRORS 


Errors  In  the  Writer  can  be  divided  Into  three  classes  according  to 
their  degree.  The  most  serious  cause  the  Writer  lomedlately  to  terminate 
with  a FORTRAN  STOP  statement.  Less  serious  errors  will  print  a message, 
cause  an  error  recovery  action  to  be  Initiated  which.  In  turn,  continues 
execution.  These  errors  generally  have  a multiplicative  effect  and  force 
more  errors  as  the  Writer  continues  to  execute.  Finally,  there  are 
warnings  «Wi1ch  generally  refer  to  problems  with  Items  within  records.  For 
almost  every  application,  all  nonfatal  errors  and  warnings  must  be  corrected 
thus,  forcing  a rerun  of  the  Writer  and.  In  some  extreme  cases,  a rerun  of 
other  Translator  modules.  Sophisticated  users  can  correct  some  minor 
problems  by  writing  a special-purpose  program  to  alter  the  target  database 
If  a rerun  of  the  Writer  cannot  be  justified. 

Documentation  for  all  Writer  errors  appears  In  this  appendix.  Each 
error  message  Is  given  a number  and  cross-references  are  sometimes  made. 
Information  as  to  trfwther  or  not  the  error  Is  fatal /nonfatal , which  activity 
the  error  occurs  In,  cause,  the  action  to  be  taken  to  correct  each  error, 
are  given.  All  occur  In  activity  #4  and  are  sorted  alphabetically  to 
allow  easy  reference.  The  collating  sequence  followed  Is: 

1)  Numeric  characters. 

21  Alphabetic  characters. 

3)  Special  characters. 


1 . "RECORD  TYPE  NOT  STORED  IS  - 

MASTER  RECORDS  HAVE  NOT  BEEN  STORED "YET, 


PROBABLE  CAUSE  - ALL  OF  ITS 


Cause:  A run  of  the  Writer  on  only  part  of  the  database  has  failed  to 
store  the  record  type  mentioned  In  the  error  message  because  the 
master  of  th*s  record  type  was  not  specified  by  the  user  to  be 
written  on  this  or  a prior  run.  This  Is  a nonfatal  error. 

Action:  Rerun  the  Writer  by  Including  the  master  of  this  record  type  among 
those  to  be  written,  or  remove  this  record  type  from  the  list  of 
those  to  be  written. 


"HIERROR 

RECORD- 


ADBMS  ERROR  OCCURRED  DURING  RETRIEVER  ATTEMPT  TO  GET 
FIELD  NAME- WITH  DBKEY- " 

Accompanied  by  the  AOBMS  trace  listing  on  RC-06,  a Writer 
Initializing  routine  suffered  an  ADBMS  error.  This  fatal  error 
Is  a sign  of  seriously  damaged  target  SDDL  tables  and/or  a 


Cause 


program  logic  error. 

Action:  Make  sure  the  IDS  Analyzer  run  that  produced  the  target  SDDL 
tables  terminated  normally  with  no  errors.  It  Is  doubtful 
that  the  Restructurer  or  TDL  Analyzer  could  have  executed 
successfully  If  this  error  occurs.  If  all  else  falls-,  contact 
the  Data  Translation  Project. 


3.  "###ERROR. . .ADBMS  ERROR  OCCURRED  WHILE  ATTEMPTING  TO  LOCATE  DETAIL  TYPE 
OF  THESE  PREVIOUSLY  STORED  MASTERS  - IDS  REC  TYPE  STORED  FLAG" 

Cause:  The  Writer  was  attempting  to  determine  which  detail  type  was 

to  be  stored  next  when  this  fatal  error  occurred.  The  following 


1$  a list  of  possible  causes 

1.  The  SOOL  tables  have  been  damaged  as  In  error  #2. 

2.  The  user  has  changed  the  record  type  Identification 
numbers  between  compiling  the  target  MD  section  In 
activity  3,  and  the  time  that  the  target  SDOL  tables 
were  created  by  the  IDS  Analyzer. 


3.  A disjoint.  Invalid  IDS  structure  was  defined  In  the 
target  MD  section. 

The  first  two  causes  are  self-explanatory;  the  third  requires 
examination  of  the  error  message.  Draw  a picture  of  the  database 
marking  the  records  with  an  "X"  If  stored  by  this  point  (indicated 
by  a "1"  in  the  STORED  column).  There  must  be  at  least  one 
record  that  Is  a detail  of  only  records  marked  with  an  "X"*  if 


Action 


not,  an  Invalid  IDS  structure  has  been  defined 


4.  "###ERR0R... ADBMS  ERROR  OCCURRED  WHILE  ATTEMPTING  TO  LOCATE  OWNER 
RECORDS  (GETOWN)  FOR  TYPE  - 

Cause:  See  error  #2. 


Action:  See  error  #2 


5.  "###ERR0R... DATABASE  NAME  NOT  FOUND###" 

Cause:  The  name  of  the  database  supplied  to  the  Writer  by  the  user  as 

a run-time  parameter  Is  invalid.  This  Is  a fatal  error. 

Action:  Check  to  be  sure  that  the  database  name  is  spelled  correctly  and 
that  this  database  is  described  by  the  SDOL  tables 

f . • a a a . a aA.  * 


Included  ip  the  JCL 


###ERR0R. . , OBNAME  IS  EMPTY###" 

The  user  has  not  supplied  the  name  of  the  database  the  Writer  Is 
to  work  on  as  a run-time  parameter.  This  Is  a fatal  error. 

Action:,  Correct  the  JCL  so  that  the  first  line  of  the  data  file  assigned 
to  I/O  device  15  is  the  name  of  a database  consistent  with  Its 
name  In  the  SODL  tables. 


Cause 
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7.  "###ERROR... ERROR  IN  6TSYOW,  CAN'T  FIND  SYSTEM  SET  NMC  FOR-_ " 

Cause:  Certain  records  la  the  SOOL  tables  Mart  built  Incorrectly  or 

tht  Writer  has  damaged  Itself  ^ 
during  execution.  This  Is  a nonfatal  error. 

V 

Action:  Check  the  IDS  Analyzer  for  run  errors.  If  none  can  be  found, 

contact  Data  Translation  personnel. 

' ’ . » 

• • • . ■ - 

8.  -IlfERROR... ERROR  IN  NODCHT,  UNABLE  TO  MODIFY  CHAIN  TABLES  FOR  MASTER 

RECORD  IDENTIFIED  BY-^ FQR  CHAIN- 

Cause:  An  Invalid  IOS  Definition  Structure  was  created  because  an  erroneous 
ND  section  was  written.  This  Is  a nonfatal  error. 

5e«v,,K'  3 

Action:  Ensure  that  the  compilation  of* the  ND  section  in  activity  3 mat  correct. 
See  also  solution  for  error  #9. 


9.  "MfERROR. . . FOMOD  DISCOVERED  INVALID  IDS  STRUCTURE  TABU,  ERROR#  - 

Cause:  An  invalid  IDS  structure  was  defined  In  the  target  ND.  The  IDS 
Translator  does  not  catch  all  semantic  errors  In  the  coding.  The 
error  # Is: 

•*  - No  ROs  In  structure  table 

3 - A field  Increment  and  field  length>3813 

4 - Last  fD  pointer  does  not  point  to  an  RD 

5 - Last  RD  pointer  does  not  point  to  CCBLC 

It  Is  possible, that  if  activity  3 was  not  checked  for  errors 
this  message  will  appear.  It  Is  a fatal  error. 

Action:  Chedc  activity  3 for  errors.  Check  also  to  make  certain  that 

each  96  CHAIN  MASTER  entry  has  at  least  one  98  CHAIN  DETAIL  entry. 
Carefully  examine  the  MD  section  for  syntax  errors  that  IOS 
might  not  detect. 

« . ■ i . 

« 

10.  M###ERR0R...6ETNXT  ROUTINE  RETURNED  AOBMS  ERROR  OF-  , ATTEMPTED 

TO  RETRIEVE  TYPE- 

Cause:  SMerror  #2.  This  Is  a nonfatal  error. 

Action:  See  error  #2. 


11.  *###EAR0R...6EYRD  SUFFERED  SOME  ERROR,  FOR  IDSREC- , RECORD  NAME 

m * 


Cause:  A'Mriter  Initializing  routine  could  not  locate  a record  definition 
fOr  the  given  record  name.  It  was  probably  caused  by  an  Invalid 
IDS  Definition  Structure.  This  Is  a.fetal  error. 

Action:  Sams  as  error  #9. 


«•  e^OJOOCUR  FOR  OBKEjV_  MNILE  tXKMCING 

FOR  OWNER  OF  DETAIL  TYPE-  OWNER  - SET^ 

OETAIL  INSTANCE  ICMORED" ■ “~7~  J 

Cmm:  The  record  mu  not  Hiked  up  on  the  sot  specified  by  the 

instruct urer.  This  error  alnost  always  occurs  because  the  TDL 
ims  not  written  correctly  for  the  application.  Coupled  with 
error  138.  This  1$  a nonfatal  error. 

* v • ■ • * 

Action:  Check  the  TDL,  rewrite  and  rerun  the  tDL  Analyzer  and  RestructurOr. 


6ETIR^  HAD 


14.  i##iERROR^. . IMPOSSIBLE  TO  INITIALIZE  ADBMS  DATA  BASES.  ERROR  CODI 
- EXECUTION  TERMINATED" 

Cause:  Inproper  JCL  for  executing  the  Writer,  This  Is  a fatal  error 
Action:  Check  file  code  asslgrments  as  specified  In  Section  >17. 


Cause:  Ths  user  has  substituted  or  changed  the  target  HD  section  between 
the  creation  of  the  target  SDDL  tables  and  the  execution  of  the 
• Writer.  In  particular,  the  location  of  the  chain  pointer  fields 
has  ndt  regained  constant.  This  Is  a nonfatal  error. 

Action:  Hake  sure  the  98  level  entries  have  not  been  transposed  since 

the  IDS  Analyzer  run.  All  Ite*  lengths  should  reuain  constant.  . . 
If  an  error  Is  found,  rerun  the  Writer  after  correcting  the  HD, 


16.  "###ERR0R. . . IMPOSSIBLE  TD  OPEN  TARBET  SDDL" 

% 

Cause:  laproper  JCL  for  executing  the  Writer.  This  Is  a fatal  error 
Action:  Check  file  code  asslgmnents  specified  In  Section  *9,7. . 


"###ERR0R... IMPOSSIBLE  TO  STORE  REFERENCE  CODE 
A POSITIVE  VALUE  FROM  SFK. ; IERR  ■ J* 

i*  Creation  of  the  target  RIFMJSi  execute" 
successfully.  Error  In  the  DOTwmer  dur 


ring  Restructurer  run 


Action:  Chock  tho  output  of  the  DOL  Writer  from  the  Res true turer  for 

errors.  Erroneous  Inforeetlon  eeens  that  the  target  SODL  tables 
were  not  properly  created.  Refer  to  the  section  on  the  IDS 
Analyzer. 


"###ERROR. . . IMPOSSIBLE  TO  STORE  REFERENCE  CODE  OF  TARGET  RECORD- 

WITH  DBKEY  IN  RIF  OF-  PROCESSING  CONTINUES  BUT  ERRORS  MAY  OCCUIT 
LATER  WHEN  ATTEMPT!  NGTlTTrORE  DETAIL  RECORDS  OF  THIS  MASTER" 


See  error  #17.  This  Is  a nonfatal  error 


Action:  See  error  #17 


"###ERROR. . . INCONSISTENCY  BETWEEN  TARS  ROUTINE  GTDETL  WHICH  CLAIMED 

THAT  TYPE- HAD  MASTER  TYPES  AND  ROUTINE  GETONN  WHICH  COULDN’T 

FIND  ANY  MASTER. 


Action:  See  error  #2 


20.  "###ERROR. . . INCONSISTENCY  IN  ROUTINE  GETONN,  RECORD  TYPE 
MAS  NOT  RETURNED  IN  INITIALIZATION  ROUTINE  GETREC" 


Action:  See  error  #2 


N###ERROR... INVALID  RUN-TIME  INPUT,  FORMAT  MUST  BE  A6,  IX,  A6.  VALUES 
READ  WERE  - " 


The  second  line  of  data  residing  on  file  code  IS  Is  not  In  the 
proper  format  to  be  used  es  a run-tine  Input  paraMter(s).  This 
Is  a fetal  error. 


Action:  Make  sure  that  the  Input  paraMters  to  the  Writer  are  as  sped 


22.  ”###ERROR... INVALID  USER  SPECIFIED  RECORD  TYPE  NAME,  EXECUTION  CONTINUES 
INVALID  NAME  IS " 


Cause:  The  user  has  supplied  a record  type  na m on  file  code  15  which  Is 
not  a record  type  In  the  target  database  to  be  created  by  the 
Writer.  This  Is  a nonfatal  error. ' 

Action:  Check  the  Writer  JCL  to  be  sure  that  the  record  type  iwm  Is 

spelled  and  formatted  properly.  Check  also  to  be  sure  that  the 
target  database  file,  the  SDOL  tables  file,  and  the  database  on 
file  code  15  are  consistent. 


23.  *###ERRQR... LENGTH  OF- DISP  OF- FOR  ITEM-  OF  RECORD- 

EXCEEOS  BUFFER  MAX  OF  55RTCHARACTEl5,,-“  ~ 

Cause:  While  building  a target  record,  one  of  the  Writer's  Internal 

vectors  overflowed  because  the  sun  of  the  record's  Iten  lengths 
was  too  large.  This  Is  a nonfatal  error. 

Action:  Either  redesign  the  target  database  so  that  the  record  will  not 
be  greater  than  3840  characters  or  contact  the  Data  Translation 
Project  to  modify  the  Internal  table. 

24.  "###ERR0R. . .MASTERLESS  RECORD  TYPE  OF- DOES  NOT  EXIST  WITHIN 

OBTGNM  VECTOR  RETURNED  BY  fiTRECS.  EXECOTTOK  CONTINUES" 

* % 

; s 

Cause:  The  target  SDDL  tables  have  been  seriously  damaged  since  their 
creation.  This  error  would  appear  only  under  very  unusual 
circumstances.  It  Is  a nonfatal  error. 

Action:  See  error  #2. 


###ERR0R... NEGATIVE  NUMBER  ENCOUNTERED  IN  'STORED'  ARRAY.  NUMBER 


Cause:  An  internal  Writer  vector  has  an  element  whose  value  Is  negative. 
This  Is  a fatal  error. 

Action:  This  error  can  occur  only  If  the  Integrity  of  the  data  stored  on 
file  code  16  has  been  violated,  or  If  there  Is  a program  logic 
error  of  the  Writer.  In  either  case,  contact  the  Data  Translation 
Project. 


26.  "###ERR0R...N0  MAPPAR  ELEMENTS  FOR  RELAY- " 

Cause:  Error  In  construction  of  SDDL  tables  for  target  IDS  database. 
No  Indication  was  made  of  the  location  of  pointer  Items  that 
Implement  this  relation.  Check  SDDL  table  creation  run  and 
examine  user  dunp  closely.  This  Is  a nonfatal  error. 

Action:  If  no  error  can  be  found,  contact  Data  Translation  Project, 
otherwise  correct  extended  target  MD  section,  rerun  the  IDS 
Analyzer  and  then  rerun  the  Writer.  If  the  user  error  would 
have  had  an  Impact  on  the  Integrity  of  the  Restructuring  . 
execution,  then  the  TOL  Analyzer  and  Restructurer  must  alto  be 
rerun  prior  to  Writer  execution. 


27.  "###ERR0R. ..NOT  POSSIBLE  TO  OPEN  TARGET  RIF" 

Cause:  Incorrect  JCL  setup  for  Writer  execution.  This  Is  a fatal  error. 

Action:  Check  the  JCL  to  ensure  that  file  02  Is  a random  file  which  repre 
sents  the  target  RIF  database. 


28.  "###ERROR. . .NUMBER  OF  MASTER-LESS  RECORD  TYPES  IS  NOT  BETWEEN  1 
AND  50.- 

Cause:  The  user  has  violated  a Writer  Internal  limitation.  There  cannot 
be  more  than  50  or  less  than  1 record  types  that  do  not  have 
masters,  e.g. , are  not  described  by  a 98  CHAIN  DETAIL  (other  than 
CALC).  This  Is  a fatal  error. 

Action:  Redesign  target  database  so  that  the  above  restriction  Is 
observed. 


29.  N###ERR0R... NUMBER  OF  TARGET  IDS  RECORDS  IS  NOT  BETWEEN  1 AND  75, 

NUMREC  - , IF  NUMREC  >75,  VECTORS  MUST  BE  REDIMENSIONED  AND 

PROGRAM  RECOMPILED" 

Cause:  The  user  has  attempted  to  create  a target  database  of  greater  than 
75  record  types  and  has  thereby  exceeded  the  Writer's  Internal 
table  size.  This  Is  a fatal  error. 

Action:  Several  vectors  In  the  Writer  and  the  program  code  which  checks 
table  size  overflow  must  be  changed  and  the  program  recompiled. 
This  should  be  done  only  by  Data  Translation  personnel.  An 
easier  solution  Is  to  design  a smaller  target  database. 


EXCEEDS 


30.  "###ERRQR... NUMBER  OF  UNIQUE  FIELOS  IN  RECORD  TYPE 

WRITER  MAXIMUM  OF  60." 

Cause:  The  user  has  violated  a Writer  limitation  of  80  fields  per 

record  size.  This  Is  a fatal  error. 

Action:  Redesign  the  target  database  and  start  over.  Alternatively 
contact  the  Data  Translation  Project  to  modify  the  Writer. 


###ERR0R... OWNER  OF  SET- WAS  NOT  STORED,  DETAIL  IGNORED 


While  attempting  to  store  a record  type,  the  Writer  discovered 
that  not  all  of  this  record  type's  masters  had  been  previously 
stored.  Therefore,  the  detail  could  not  be  stored.  Generally 
a result  of  previous  error  #12's  occurrence  higher  In  the  data 
base  structure*,  This  Is  a nonfatal  error. 


Cause 


Action:  Make  sure  that  the  Writer  is  supplied  with  the  name  of  the 

owner  record  of  the  set  mentioned  on  the  next  run  of  the  Writer 


IS  DETAIL  IN  GREATER  THAN  10  CHAINS,  EXCEEDS 


32.  "###ERR0R... RECORD 
WRITER  MAX." 


A record  Is  defined  In  the  target  database  as  a detail  In  more  than 
10  chain  relations.  This  has  caused  a Writer  table  to  overflow. 
This  Is  a nonfatal  error. 

Redesign  the  database  or  contact  the  Data  Translation  Project. 


Cause 


Action 


"fffERROR... ROUTINE  SETTOP  CLAIMS IS  A DETAIL  RECORD  BUT 

ROUTINE  6TDETL  CLAIMS  THAT  IT  IS  NOm’MRBER  OF  ANY  SET." 


Cause:  Internal  Writer  logic  error.  This  Is  a fatal  error 
Action:  Contact  Data  Translation  Project. 


34.  "###ERROR... ROUTINE  GTDETL,  IS  AN  OWNER  OF 

IN  0RI6INAL  LIST  OF  LEGAL  GROUPS" 


Cause:  Internal  Writer  logic  error.  This  is  a fatal  error 

Action:  Contact  Data  Translation  Project. 


WHILE  LOOKING  FOR 


35.  "###ERROR... ROUTINE  GTFLD  SUFFERED  ADBMS  ERROR 
FIELDS  OF  RECORD  TYPE- 


Cause:  Accompanied  by  an  ADBMS  traceback , this  error  Indicates  serious 
problems  with  the  target  SDDL  tables.  This  Is  a nonfatal  error 

Action:  See  error  #2. 


36.  "fffERROR. . . SUBROUTINE  VALREC  HAS  RETURNED  AN  ILLEGAL  RETURN  COOE 
RETURN  CODE  • * 


Cause:  A parameter  passed  back  to  the  Writer  from  a support  module 
Is  Illegal.  This  Is  a fatal  error. 

Action:  This  error  can  occur  only  as  a result  of  a serious  program 
logic  error.  Contact  the  Data  Translation  Project. 


"fffERROR. . .SUMSCM  RETURNS  ERROR  COOE  OF-  EXPLANATION,  SEE  SUMSCM 
DOCUMENTATION" 


Cause:  A Wrl ter  routine  that  modifies  bits  In  detail  definition  records 
of  the  IDS  Definition  Structure  discovered  an  Invalid  structure. 
This  Is  a fatal  error. 

Action:  Check  activity  3 output  for  correct  compiling  by  IDS  Translator. 
The  error  Is  In  96  CHAIN  MASTER  entries.  Correct  and  rerun  the 
Writer. 


38.  “###ERROR...THE  RECORD  - IDENTIFIED  BY  KEY  * IS  NOT  AN 
INSTANCE  OF  SET  - * * 


Cause  See  error  #12,  This  Is  a nonfatal  error. 
Action:  See  error  #12. 


39.  "###ERR0R. . .USER  RECORD  TYPE  HAS  ALREADY  BEEN  WRITTEN.  RECORD  NAME 
IS:  DATE  WRITTEN:  " 

Cause:  The  user  has  Included  on  file  code  15  the  name  of  a record  to  be 
written  Into  the  target  database  on  this  run  of  the  Writer,  but 
this  record  type  has  already  been  processed.  This  Is  a nonfatal 
error. 

Action:  None  Is  necessary  unless  a clean  output  listing  is  desired.  If 
so,  remove  the  offending  record  name  from  the  file  residing  on 
file  code  15. 


40.  ###ERROR. . .USER  SUPPLIED  DATABASE  NAME  IS  NOT  THE  SAME  AS  THE  ONE 
STORED  ON  FILE  COOE  16.  USER'S  CURRENT  DATABASE  ON  FILECODE 
16  IS " 

Cause:  While  attempting  to  run  the  Writer  using  Its  partial  database 
write  capability,  the  user  has  supplied  the  name  of  a database 
on  file  code  15  which  does  not  match  the  name  of  the  database 
residing  on  file  code  16.  This  Is  a fatal  error. 

Actton:  Check  the  JCL  setup  to  be  sure  that  all  file  names  supplied  are 
consistent  with  Writer  JCL  rules  and  the  user's  Intent.  Make 
sure  that  the  database  name  supplied  on  file  code  16  is  spelled 
correctly  and  is  left- justified. 


41.  "###ERROR... WHILE  ATTEMPTING  TO  STORE  THE  RECORD  - AN  IDS  ERROR 

OCCURRED  OF  #- “ 

PROCESSING  CONTINUES  BUT  ERRORS  MAY  PROPAGATE  WHILE  CONTINUING1' 

Cause:  Refer  to  the  IDS  manual  for  an  explanation  of  the  error  muter. 
Typical  errors  are  duplicate  CALC  records  or  space  overflow. 

This  Is  a nonfatal  error. 

Action:  Depending  on  the  error,  either  the  TDL  may  have  to  be  rewritten 
forcing  a new  Restructurer  run,  or  the  target  MD  section  must  be 
modified  by  expanding  page  ranges  or  percent  fill.  If  the  latter 
action  Is  taken,  the  Writer  must  be  rerun. 


43.  "###MARNIN6. . . IDS  LENGTH  OF- 
OF  RECORO  NAME-FIELD  IGNORED' 


42.  B##HIARNING...IDS  DISPLACEMENT  OF  - IS  NOT  VALID  FOR  ITEM 

NAME  - OF  RECORO  NAME  - FTECff  IGNORED" 

Cause:  The  displacement  of  an  Item  fs  less  than  zero.  Result  of  serious 
error  In  the  creation  of  target  SDOL  tables.  This  Is  a nonfatal 
error. 

Action:  Check  IDS  Analyzer  run  for  errors.  If  none  are  found,  contact 
the  Data  Translation  Project. 


Cause:  The  length  of  an  IDS  Item  Is  less  than  or  equal  to  zero.  This 
Is  a nonfatal  error. 

.... 

Action:  Check  IDS  Analyzer  run  for  errors. 

44.  "###WARNING... ILLEGAL  TYPE  VALUE  OF- FOR  ITEM- OF  RECORD- 

Cause:  Generation  of  Item  type  values  by  the  IDS  Analyzer  was  Incorrect. 
The  only  legitimate  values  are  Integers  1-7.  This  Is  a nonfatal 
error. 

Action:  Check  TDS  Analyzer  run  to  ensure  that  for  all  Items  created,  a 
legitimate  type  was  created. 


Final  Comments  on  Error  Messages 


All  errors  that  occur  while  calling  the  ADBMS  routines  appear  with 
a traceback  of  calls  and  arguments  on  report  code  06. 

Several  errors  In  the  Writer  are  accompanied  by  an  octal -BCD  dump 
of  the  first  five  or  seven  words  of  the  record  Involved  In  the  error. 

If  seven  words  are  printed.  It  Is  the  IDS  record  and  the  Items  arm  stored 
In  exactly  the  same  sequence  as  they  appear  In  the  target  MD  section. 

When  five  words  appear,  they  represent  the  first  five  words  of  a target 

RIF  data  record  in  which  the  Items  are  stored,  ordered  In  a non-determlnlstlc 

manner. 

Many  of  the  writer  errors  point  to  serious  problems  in  the  execution 
of  the  Translator  code.  It  Is  to  be  expected  that  system  programmer 
Intervention  may  be  required  to  correct  the  error.  If  the  target  SDOL 
tables  have  not  beeni altered  since  their  creation  by  the  IDS  Analyzer, 
many  of  the  possible  Writer  errors  will  already  have  been  uncovered  by 
the  TDL  Analyzer  or  Restructurer  runs. 


F.O  ADBMS  OVERVIEW 
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ADBMS,  like  IDS,  Is  a database  management  system  which  facilitates 
the  creation,  maintenance  and  accessing  of  simple  and  complex  data 
structures.  It  consists  of  a collection  of  FORTRAN-callable  subroutines 
whose  purpose  Is  to  create  databases  from  a user's  data  structure  descrip- 
tion, and  to  serve  as  an  Interface  between  the  user  and  these  databases. 
ADBMS  Is  used  by  the  Data  Translator  as  follows: 

IDS  Analyzer 

a)  creates  SODL  tables  (AD8MS  database) 

b)  uses  Internal  Work  Database  (ADBMS  database)  Internally 

TDL  Analyzer 

a)  retrieves  Information  from  source  and  target  SDDL  tables  (ADBMS 
databases) 

b)  creates  TDL  tables  (ADBMS  database) 


Reader 

a)  uses  source  SDOL  tables  (AOBMS  database)  as  Input 

b)  creates  source  RIF  (ADBMS  database) 

c)  uses  DRT  (ADBMS  database) 


Restructurer 


retrieves  data  from  source  RIF  (ADBMS  database) 
stores  data  In  target  RIF  (ADBMS  database) 
accesses  TDL  tables  (ADBMS  database) 


Writer 


a)  uses  target  SDDL  tables  (ADBMS  database)  as  Input 

b)  uses  target  RIF  (ADBMS  hash  database)  as  Input. 


F.l  Describing  an  ADBMS  Database  — The  DDL 

Every  ADBMS  database  Is  logically  described  in  terms  of  sets,  records, 
and  Items.  These  ADBMS  constructs  are  similar  to  the  IDS  chain,  record, 
and  field  constructs.  Records  are  composed  of  Items  and  are  related  by 
sets. 

There  are  two  types  of  ADBMS  records,  hash  and  non-hash,  whose  principle 
difference  lies  In  the  method  used  to  store  them.  While  non-hash  records 
are  simply  stored  In  the  next  available  space  In  the  database,  the  storage 
algorithm  used  for  hash  records  Is  similar  to  that  of  the  IDS  calculated 
record.  That  1$,  one  or  more  Items  In  the  hash  record  are  specified  as 
primary  key  Items  and  are  hashed,  or  randomized,  to  determine  the  location 
of  the  record  In  the  database. 

There  are  also  two  types  of  ADBMS  sets,  ordered  and  match-key,  which 
are  defined  In  terms  of  their  owner  and  member  record  types,  just  as  IDS 
chains  have  master  and  detail  record  types.  Ordered  sets  can  be  used  to 
specify  relationships  among  records  and  may  be  ordered  In  a variety  of  ways. 
An  AOBMS  ordered  set  differs  from  an  IDS  chain  In  that  It  Is  allowed  more 
than  one  owner  record  type.  The  second  type  of  ADBMS  set,  the  match-key 
set,  can  have  only  one  owner  record  type  which  must  be  a hash  record.  The 
member-to-owner  relationship  Is  established  by  storing  the  primary  key 
Items  of  the  owner  of  the  set  In  the  set-significant  Items  of  the  member. 

The  Data  Description  Language,  or  DDL,  Is  a language  used  to  describe 
a database  In  terms  of  the  constructs  specified  above.  A specific  database 
description  written  In  this  language  Is  also  called  a DOL  and  corresponds 
to  the  IDS  MD  Section. 
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F.2  The  POL  Analyzer/Database  Initializer 

The  DOL  Analyzer/Database  Initializer  Is  a utility  routine  used  In 
creating  AOBMS  databases.  The  first  step  In  the  creation  of  an  ADBMS 
database  Is  the  writing  of  a DDL  to  describe  It.  This  DDL  and  some  optional 
hash  Input  Information  are  then  Input  to  the  DDL  Analyzer/Database  Initial- 
izer whose  purpose  Is  twofold.  First.  It  analyzes  the  DDL  description  of 
the  database,  and  checks  for  syntactical  errors  and  Inconsistencies.  This 
first  stage  Is  similar  In  function  to  that  of  the  IDS  Translator.  If  It 
Is  successful,  the  database  tables  are  produced  and  used,  along  with  the 
optional  hash  Input,  to  Initialize  the  ADBMS  database.  The  second  stage, 
comparable  to  the  IDS  program  QUTI,  involves  the  determination  of  the  para- 
meters to  be  used  by  the  hashing  algorithm  to  store  hash  records.  The  user 
has  the  option  of  specifying  some  or  all  of  these  parameters  as  hash  Input 
to  the  00L  Analyzer/Database  Initializer,  or  simply  accepting  default  values 
determined  during  initialization.  Figure  F-l  summarizes  the  function  of 
the  DDL  Analyzer/Database  Initializer.  Alternate  modes  of  operation  allow 
the  user  to  forego  the  database  Initialization  stage  and  receive  as  output 
only  the  database  tables,  or  to  input  the  database  tables  Instead  of  the 
DDL  and  bypass  the  DDL  analysis  stage. 

F.3  The  ADBMS  Database  and  Database  Tables 

An  Initialized  ADBMS  database  consists  of  physical  pages  on  which  all 
Information  in  the  database  Is  stored.  The  database  tables  produced  during 
the  DDL  analysis  stage  of  the  DDL  Analyzer/Database  Initializer  are  stored 
on  the  first  page(s)  of  the  database.  They  contain  the  logical  description 
of  the  database  according  to  the  DDL  and  are  comparable  to  the  IDS  Definition 
Structure.  The  remaining  pages  are  Initialized  according  to  a specific 
format  very  similar  to  the  pages  of  an  IDS  database.  Before  operations 
can  be  performed  on  a database,  the  database  must  be  opened,  at  which  point 
Its  tables  are  read  from  the  database  back  Into  core  where  they  are  used  to 
retrieve  descriptive  Information  about  the  database  and  to  store  additional 
Information  required  by  ADBMS  when  performing  operations  on  the  database. 

ADBMS  databases  which  contain  hash  records  are  often  referred  to  as 
hash  databases;  those  not  containing  hash  records  are  referred  to  as  non- 
hash databases. 

F.4  Multiple  Databases 

ADBMS  has  the  capability  to  manage  multiple  databases  simultaneously. 
That  Is,  operations  can  be  performed  first  on  one  database  and  then  another 
without  closing  the  first  database  and  opening  the  second  database  between 
operations.  This  capability  Is  made  possible  by  the  concept  of  a current 
database.  Rather  than  close  one  database  and  open  another,  the  user  keeps 
all  necessary  databases  open  at  the  same  time  and  simply  resets  the  current 
database.  All  database  tables  corresponding  to  open  databases  are  In  core 
simultaneously;  one  set  of  them  Is  associated  with  the  curren*  database. 

F.5  Database  Keys 

Each  physical  record  stored  In  the  database  Is  uniquely  Identified  by 
Its  database  key.  A database  key  specifies  the 

page  and  displacement  within  that  page  where  the  record  Is  located.  Whenever 
a record  Is  accessed,  the  page  on  which  It  Is  stored  must  be  brought  Into 
core. 
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Figure  F-l 

DDL  Analyzer/Database  Initializer 
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F.6  The  Work  Database 


When  there  Is  a limitation  on  the  number  of  pages  which  can  reside  In 
core  simultaneously,  pages  must  often  be  written  back  out  to  their  data- 
bases to  make  room  In  core  for  the  pages  containing  records  currently  being 
accessed.  To  minimize  time  spent  changing  pages  In  and  out  of  core,  a 
pseudodatabase,  the  work  database,  can  be  used.  The  work  database  Is  a 
temporary  ADBMS  database  which  has  no  database  tables  and  whose  pages  are 
permanently  In  core.  Frequently  referenced  records  from  other  databases 
may  be  temporarily  copied  Into  and  accessed  from  the  work  database  so  that 
their  pages  need  not  be  continually  changed  In  and  out  of  core.  The  work 
database  Is  automatically  destroyed  when  all  open  databases  are  closed. 


F.7  Restrictions  on  ADBMS 

The  following  factors  are  limited  by  variables  In  the  ADBMS  block  data: 

a)  the  number  of  pages  allowed  In  core  simultaneously, 

b)  the  number  of  databases  allowed  open  simultaneously,  and 

c)  the  lengths  of  the  database  tables  of  open  databases. 

Attempts  to  exceed  the  limits  b)  and  c)  will  result  In  an  ADBMS  error. 

These  limits  may  be  changed  simply  by  altering  the  block  data  which  Is 
compiled  Into  the  Data  Translator  R*  modules. 

The  amount  of  data  which  may  be  stored  In  a database  Is  restricted  by 
the  size  of  the  database  specified  at  the  time  of  Initialization.  Attempts 
to  exceed  this  limit  will  also  result  In  an  A06MS  error.  The  only  way  to 
overcome  this  difficulty  Is  to  reinitialize  the  database. 

All  data  (Items)  stored  In  ADBMS  databases  must  be  of  one  of  six  types: 
Integer,  real,  binary,  database  key,  logical,  or  character.  The  length  of 
an  Item  depends  on  Its  type;  Integer,  database  key  and  logical  Items  are 
one  word  In  length,  real  Items  are  two  words  In  length,  and  binary  and  char- 
acter Items  may  be  up  to  256  bytes  long. 


0 

1 

3 

.1 

3 

3 

oi 

d 

o 

- 

Oj 


F.8  Error  Messages 

When  an  error  occurs  In  an  ADBMS  subroutine,  an  error  code  Is  returned 
and  the  appropriate  message  Is  output.  The  message  Indicates  what  the  error 
Is,  where  It  occurred,  the  number  of  the  current  database,  whether  or  not 
the  work  database  (work  area)  has  been  Initialized  and  whether  or  not  It 
Is  the  current  database.  A utility  routine,  D6TRCE,  prints  Information  about 
the  sequence  of  subroutine  calls  which  led  to  the  error,  and  the  parameters 
of  each  call.  A sample  error  message  output  Is  given  In  Figure  F-2. 
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*1531 
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iRPOH  # 17  1.1  CRX  (LrIV=L 

;«()«;<  area  initialized.  #1529 
iiORa  AREA  CLRREuT.  #1530 

ROUTINE  LBTRCE.  STATEMENT 
PARAMETER  ADDR  BCD 

1 000000070  1 1 1 000000  000000000000 

ROUTINE  DBEPR  , STATEMENT  99  #1534 

PARAMETER  ADDR  BCD  OCT 

1 000000065701  000006  000000000006 

2 000000065702  000000  000000000000 

ROUTINE  CRX  , STATEMENT  158  #1538 
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INTEGER 


INTEGER 


000000130502  0000 IE  0000000*30125 
000000130503  OOOOOA  000000000021 
STKpRP,  STATEMENT  118  #1542 


PARAMETER  ADDR  BCD  OCT 

1 

2 

ROUTINE 

PARAMETER  ADDR  BCD  OCT 

1 000000114717  0000 I R OOOOOOOOI25I 

2 000000114720  000000  000000000000 

3 000000 11 #721  OOOOOA  000000000021 

ROUTINE  STKBLD,  STATEMENT  160  #1547 
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I 000000110226  000000  000000000000 

ROUTINE  .......  STATEMENT  153  #1550 
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Figure  F-2 

ADBMS  Error  Message  Output 

The  following  Is  an  explanation  of  all  possible  error  codes. 

01  DINT  HAS  NOT  BEEN  CALLED 

02  INVALID  SET  TYPE 

03  INVALID  RECORD  TYPE 

04  INVALID  ITEM  TYPE 

05  INVALID  OWNER  TYPE 

06  INVALID  MEMBER  TYPE 

07  INVALID  DATABASE  KEY 

06  NO  CURRENT  OWNER  OF  SET 

09  NO  CURRENT  MEMBER  OF  SET 

10  NO  CURRENT  OF  RECORD  TYPE 

11  ALREADY  MEMBER  OF  SET 

12  RECORD  NOT  MEMBER  OF  SET 

13  DEPENDED  ON  ITEM  OUT  OF  RANGE 

14  DATABASE  ALREADY  OPEN 

15  DDL  TA8LES  INCONSISTENT 


o o 


16  DATABASE  INCONSISTENT 

17  DATABASE  OVERFLOW 

18  SET  TYPE  NOT  SORTED 

19  DINT  HAS  ALREAOY  BEEN  CALLED 

20  INVALID  NUMBER  OF  BUFFERS 

21  NO  CURRENT  DATABASE 

22  TOO  MANY  DATABASES 

23  ILLEGAL  I/O  UNIT  FOR  DATABASE 

24  ILLEGAL  I/O  UNIT  FOR  DATABASE  TABLES 

25  ILLEGAL  USAGE  VALUE 

26  DATABASE  TABLE  OVERFLOW 

27  ILLEGAL  CURRENT  DATABASE 

28  INVALID  OPERATION  ON  SYSTEM  RECORD 

29  DATABASE  OPENED  FOR  READ  ONLY 

34  INVALID  ITEM  POINTER 

35  INVALID  RECORD  POINTER 

36  INVALID  SET  POINTER 

37  INVALID  PAGE  NUMBER 

38  INVALID  HASH  INPUT 

39  INVALID  RECORD  STORAGE  METHOD 

40  INVALID  OPERATION  ON  PRIMARY  KEY 
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APPENDIX  G 


SYSTEM  GENERATION 


The  Version  IIA  Release  2 Data  Translator  Is  supplied  to  the  user  on 
a Honeywell  system  - standard  format  9-track  tape.  This  section  describes 
the  files  on  the  System  Generation  tape  and  the  files  a user  must  create  to 
run  the  Oata  Translator. 

The  first  file  on  the  System  Generation  tape  Is  the  table  of  contents. 
Figure  G-1  Is  the  preliminary  table  of  contents  for  the  tape.  After  the 
table  of  contents,  the  tape  contains  the  files  for  the  IDS  Analyzer,  TOL 
Analyzer,  Reader,  Restructurer,  and  Writer.  The  last  two  files  on  the  tape 
are  the  translation  library  and  the  DDL  Writer's  work  database. 

To  bring  the  Data  Translator  up  on  a system  the  user  should  complete 
the  following  steps: 

1.  Read  the  entire  User  Manual.  The  entire  Data  Translation  process 
should  be  thoroughly  understood  before  any  modules  are  run.  All 


(see  Sections  5,  6,  7,  8,  9). 

Due  to  the  large  number  of  files  used  by  the  Oata  Translator,  the 
user  will  find  It  beneficial  to  segregate  the  files  used  by  each 


module.  The  following  catalogs,  created  under  the  user's  master 
catalog,  are  recommended. 


Catalog 

/IDSAN 

/TDLAN 

/RDR 


Contents 

IDS  Analyzer  files 
TDl  Analyzer  files 
Reader  files 
Restructurer  files 
Writer  files 

Translation  library,  DDLWT  Work  database 
The  following  suffixes  should  also  be  used  on  file  names: 

Suffix 


File  content 
ADBMS  database 


Oata 

IDS  database 
ISP  Index 


Restructurer  K*  Source  Library 


Suffix 


File  content 


ISP  database 
OCL 

K*  source  library 
Random  library 
I OS  MO  section 

IOSAN  run-time  parameter  file 

R*  file 

Source  code 

Sequential  database 

Source  RIF 

SDDL  tables 

TOL  description 

Target  RIF 

TOL  tables 

Extended  IDS  MD  section 


Copy  all  files  from  the  tape  to  permanent  files.  Note  that  no  K* 
files  are  needed  to  run  the  Oata  Translator.  Sample  JCL  to  copy 
the  files  Is  In  the  first  file  on  the  tape.  The  two  random  files 
should  be  brought  off  the  tape  using  the  RREST  Utility  comnand. 
The  Reader  and  Writer's  source  code  (files  22,  23,  34,  35)  should 
be  converted  from  BCD  to  ASCII  using  BCDASC. 

Convert  all  JCL  files  to  ASCII  and  edit  the  JCL  for  each  module 
so  the  proper  files  are  referenced.  See  Sections  5,  6,  7,  8.  9 
for  the  changes  to  be  made  in  each  JCL  file.  Each  module  can  be 
run  after  completing  its  checklist  in  the  User  Manual. 


